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SECTION 1 

INTRODIJCTION AND SUMMARY 

This re.xjrt describes the MDTSCO/IBM study of packetization of the 
Spacelab data handling system, including the alternate approaches considered and the 
supporting rationale. The material presented is the result of a six-month study for 
the Marshall Space Fligh. v-unter (MSFC) to define a practical implementation. 

i.i STUDY BACKGROUND 

The coming trend in telemetry systems is toward "packetization" of data. 
Whereas systems of the past have drawn a single sample from each instrument 
consecutively and commutated the samples for downlinking, the packet concept 
devotes an entire downlinking frame or "packet" to each instrument. There are 
several important advantages to this approach and several reasons why It is becoming 
more feasible. 

An immediate benefit from packets lies In the fact that the task of data 
stripout on the receiving end is standardized, allowing a user to get his data faster 
and at less cost. A second advantage is that the capability of the downlink can be 
more efficiently apportioned among competing data sources. Rather than sampling 
every instrument on every commutating cycle, data is taken only when a packet is 
complete. 

The pacing technology item which is making the packet concept feasible 
is the advent of fast, low-cost storage devices such as are possible with large scale 
integrated circuits and bubble memories. It is becoming practical now to store large 
quantities of data on-board at the source for the formation of packets, As data 
processing and storage technology advances, an ever increasing trend toward "smart 
sensors" and extensive data reduction at the source Is inevitable. 

In anticipation of the trend toward packetization, the National 
Aeronautics and Space Administration through its Goddard Space Flight Center 
(GSFC) developed a proposed standard: Guideline 3.3, Space Data Packetization, 
Issue 1979-11-05 (ref. 1). The goal is to standardize all space telemetry systems to 
the packet format so that a common ground facility can process all space telemetry 
data. Both the Goddard Center and the Jet Propulsion Laboratory are 
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actively working toward applying packet standards to their future spacecraft . The 
Marshall Space Flight Center, which is resoonsible for design and development of the 
Space Telescope, has soecified a pacKetized system for data handling on this major 
new satellite. 

NASA Headquarters has initiated a comprehensive effort to ascertain how 
Spacelab can be converted to packet standards and the associated cost. This consists 
of three concurrent efforts; u; the Flight System Study by MDTSCO, of which this 
report is a part; (2) the Ground System Study by Ford Aerospace and Communications 
Corporation; and (3) the Instrument Study, which is currently an internal NASA 
effort. 

1.2 FLIGHT SYSTEM STUDY 

The Flight System Study was a six-month effort initiated in September, 
1580, as a modification to MDTSCO's Spacelab Integration Contract, The objective 
was to determine the most cost effective approach to packetization of Spacelab and 
to estimate the cost of conversion. The study was limited to the Spacelab flight 
system, the associated ground support equipment (GSE), prelaunch processing at the 
Kennedy Space Center (KSC) and the High Rate Demultiplexer (HRDM). Operational 
ground systems and the flight instruments were excluded, and the costs of 
packetizing these must be added to the estimates from this study. 

Three major ground rules were applied to the flight system study; 

(1) Space Data Packetization Guideline 3.3 (Nov. 5, 1979 Issue) was 
a mandatory guideline for the study, 

(2) Spacelab's performance capability was not to be upgraded or 
downgraded by packetization. 

(3) The Orblter and TDRSS downlink were assumed to be transparent. 

The November 5, 1979 issue of Guideline 3.3 was chosen as the basis for 
the study because it is the most recent version to receive wide acceptance both at 
GSFC and at NASA Headquarters. Later versions were examined and it is believed 
that the differences would have no significant effect upon the cost data or 
conclusions concerning the flight portion of the system. The second ground rule was 
adopted to ensure that only the cost of packetization is obtained. In the event that 
Spacelab is actually converted to packet format this ground rule should be suspended 
to allow consideration of other changes for concurrent implementation. 
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The Spacelab data handling system is really two systems in ones a system 
for handling data from low data rate experiments (less than 35 Kb/s) and a different 
system for high data rate experiments (up to 16 Mb/s), High rate data can be 
packetized either within Spacelab or the experiment, because Spacelab merely relays 
high rate data streams transparently to the ground. It is not appropriate to packetize 
the low rate data within the experiments however, because Spacelab performs certain 
non-transparent operations on these data streams after they leave the experiments. 

Because of the foregoing considerations, it was decided to divide the 
flight system study into two phases. The first phase assumed Spacelab would be 
required to have the on-board capability to build data packets for all experiments. 
The second phase assumed Spacelab would have to build packets only for the low data 
rate experiments, with the high data rate experiments buiiding their own packets. 
The two phases were conducted independently of each other. 

Phase I occupied the first four months of the study and resulted in the 
conceptual design of a •'full*' system capable of packetizing both low and high rate 
data. The full system is implemented by completely replacing Spacelab's High Rate 
Multiplexer (HRM) with a “High Rate Packet Multiplexer” (HRPM). The HRPM is a 
microprocessor based device requiring a three-year development cycle. 

Phase II of the study was conducted during the last two months and 
evolved the conceptual design of a "hybrid” system, which builds packets only for low 
data rate experiments. Two hybrid options were investigated: (1) performing 
packetization of low rate data within Spacelab’s existing Experiment Computer, or (2) 
adding a new component called a "Dedicated Low Rate Packetizer" downstream of 
the Experiment Computer to perform the required operation without disturbing the 
Experiment Computer. It was determined that the Experiment Computer cannot 
perform the packetization function because it has insufficient memory and processing 
speed, and does not have access to the Subsystem Computer data bus. Consequently, 
addition of the Dedicated Low Rate Packetizer is necessary if Groundrule No. 2 is to 
be satisfied. 

The crude cost analysis performed as a part of the study places the total 
cost of developtnent of the hybrid systm at $3.3 million as compared with $12.1 
million for the full system. These figures include design, development, qual testing 
and delivery of three flight units and the ground support equipment necessary for 
prelaunch processing at KSC. 
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It is the condusion of the study that, from a technical standpoint, it is 
well wititin today's state-of-the-art in microelectronics to implement either the full 
or liybrid packet data system on »ouid bpac».iab. Of the two the hybrid system is 
preferred because of lie significant cost saving. It is further recognized that the 
liybrid approach can be implemented within the ground based portion of the data 
handlirg system with theoretically identical performance, becaus*? the Spacelab 
HRM/HRDM downlink is gw^»gned to be transparent (Minimum Impact Approach). 
The ground based hybrid approach saves the flight qualification costs as well as the 
costs for two additional flight units, and avoids any weight, volume or electrical 
power penalty to Spacelab. 

Section 2 of this report gives an overview of the concept of packetized 
data and packet data handling systems. Sections 3 and describe the full and hybrid 
approaches to the packetization of Spacelab respectively. The study conclusiCMTis 
appear in Section 5. Highlights of the present Spacelab data handling system are 
included as Appendix A, and the Payload Operations Control Center format standard 
is reproduced in Appendix B for easy reference. References are given in Appendix C 
and abbreviations are listed in Appendix D. Appendix E gives a detailed description of 
KSC support for Spacelab and discusses packetization impacts to it. 
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SECTION 2 

SPACE DATA PACKETIZATION 

Because of the critical importance of data communications to American 
and international space exploration programs, the National Aeronautics and Space 
Administration (NASA) is devoting considerable attention to the advancement of 
space communications anu data handling systems. These efforts are converging 
toward a standardized packet format fo»- all space m<‘asurement data, and a common 
packet handliiig system. The major goals are to; 

0 Deliver high quality data products to the user rapidly, 
efficiently, and inexpensively. 

0 Permit instruments to acquire and transmit data at 
an instantaneous rate appropriate for the phenomenen 
being observed. 

« Adaptively allocate portions of fixed downlink bandwidth. 

♦ 

0 EncapsuUte, at the source, all the necessary data for 
the interpretation of a set of experimental observations 
(provide "data autonomy"): 

- employ a high degree of standardized interfaces, 
protocols and data structures across missions 

- maintain a constant interface to an instrument 
throughout its life cycle (bench test. Integration, 
and flight operation). 

o Facilitate modular expansion and contraction of capacity 
without compromising system integrity. 

0 Provide a data transport process which is transparent 
to the end user, and which automatically routes data 
products to their appropriate destinations. 

o Provide end-to-end accountabiity and individually tailored 
error control, 

- automatically monitor quantity, quality, and continuity 
of data 
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» provide unambiguous identification of transported data 
- allow simple message-billing of users based on resources 
consumed 

» a.iu ' a high degree of management visibility. 

9 Provide a data transport capability which is usable 
by both near-earth and deep-space missions. 

This section will briefly describe the packet format, the packet-handling 
system and the manner in which the Spacelab data handling system can be embedded 
Into the common system. 

2.1 PACKET FORMATTING 

A source packet is a well-defined sequence of bits which may correspond 
to a single observation made by a particular spaceborne instrument, A source packet 
may contain other kinds of data such as engineering or ancillary data. While it must 
conform to certain standards in order to be compatible with multi-mission facilities, 
many of its attributes can be determined by its end consumers in a way that 
maximizes its intelligibility. The basic structure of a packet is presented in Figure 2- 
1. It has a header containing control bits, a data set consisting of bits originated by a 
sensor and a trailer providing error control. 

An example of how these segments may be further defined is presented in 

Figure 2 taken from Guideline 3.3 (ref. 1). A packet has a primary header for 

control and a secondary header containing ancillary data (time, orbit, and/or 

attitude). The "SOURCE ID" bits unambiguously identify the instrument to which 

this particular packet is dedicated. The "MISSION ID" serves ^ similar purpose for 

the spacecraft carrying that instrument. Since each Instrument gives rise to an 

infinite sequence of packets, the "SOURCE SEQUENCE COUNT" identifies the 

16 

sequential order of the particular packet. Although this field recycles modulo 2 , 
two packets bearing the same source count can be distinguished from one another by 
referring to the time code in the secondary header. The "PACKET LENGTH" field 
indicates which packet length in a set of canonical packet lengths applies to this 
particular packet. The "SECONDARY HEADER IDENTIFIER" specifies the types and 
locations of an iliary data within the secondary header. In 
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order to minimize the probability of a packet being mis-routed, the "SOURCE ID 
PARITY" field provides an added degree of error control. 

Packets may include a snort "EkROR CONTROL PARITY" field. 
Experiments requiring a iiigh degree of error protection are free to employ as many 
parity bits as necessary. 

Ancillary data may be downlinked in either of two ways, depending on the 
needs of the particular users, it can be placed in the secondary header of a packet 
along with instrument source data. Alternatively, it can be placed in its own "utility" 
packet which would be appropriately registered with respect to source packets. If 
utility packets are used for downlink of ancillary data , it will be necessary to time-, 
correlate source packets with the corresponding utility packets. Interpolation may 
then be required to adjust the values in the ancillary data to the exact times of the 
data in the source packets. 

The source packet format for each instrument is defined, in conformance 
with specified requirements, by the end users of the data. This is done during the 
design phase of the mission. A packet is not subject to processing which deliberately 
alters the information content of its Source Data. It is conveyed from the spacecraft 
to its sink(s) and is presented to a sink in the same form as it had when It was 
generated. A sink may be a professor's terminal, a data base, or some special device. 
After delivery to the sink, the packet may be subjected to whatever information 
processing is deemed appropriate. 

Downlinked packets may contain instrument data, ancillary data, or 
engineering data. Some packets may be generated on the ground. For example, a 
packet may ’-oiitain link quality statistics from the space-to-ground data acquisition 
session (which may take from several minutes to a few hours for a satellite or deep 
space mission). Othe»* packets may be used to transport corollary data from ground 
instruments, such as a rainfall gauge. Thus, universal data handling facilities can 
handle all kinds of data. 

Packet telemetry is compatible with current telemetry frame standards in 
that the downlinked bit stream ir quantized into frames having sync bits and control 
headers. However, rather than placing instrument data into fixed word assignments, 
packet telemetry fills the frames with packet data. The telemetry frame (or 
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"transport frame") format prescribed by Guideline 3.3 is presented in Figure 2-3. 
Leading the frame is a header which contains various types of control data. A sync 
field is followed by the "XMT .N.ODi- lu which identifies the currently selected 
options of the l 'lemetry system (e.g., transmission rate, coding mode and 
multiplexing options), Following this is a "FRAME SEQUENCE COUNT" field which 
allows reordering of telemetry frames into chronological order if the order is 
disturbed for some rear. . The "FRAME FORMAT" field defines the length of the 
transport frame along with the number of 16-bit words contained within the "STATUS 
INSERT" field. The "SEGMENT NUMBER" field identifies how the packet contained 
within the transport frame is segmented. 

The "STATUS INSERT" field provides a means whereby 
engineering/housekeeping telemetry can be synchronously multiplexed onto the 
telemetry channel concurrent with the transmissioii of applications data packets. 

If the mission elects to use variable packet lengths, some packets may be 
too long to fit wholly within a single transport frame, which is itself of constant 
length. In such case, the. packet may be broken into segments which are downlinked 
in sequence by a series of transport frames. An example of this process is presented 
in Figure 2-k. If the mission elects to use a single packet length, each packet is 
enclosed entirely in one transport frame, with fill bits in the unused portion of the 
"PACKETIZED DATA" field. 

2.2 PACKET-HANDLING SYSTEM 

A block diagram of an end-to-end packet data handling system is shown in 
Figure 2-5. The system consists of spacecraft components, space-to-ground 
transmission equipment, ground-based data handling elements and user facilities. 
Source packets originating on board the spacecraft flow through the system, entering 
the appropriate data bases and arriving at the correct user destinations. Command 
and control data are uplinked to the spacecraft in a similar way, but at much lower 
data rates. 

2.2.1 Spacecraft Subsystem 

A functional schematic of the spacecraft subsystem is shown in Figure 2- 
6, Data from the various experiments on the .spacecraft and time Information are 
inputs to the Onboard Information Processor. This is a generic function which 
subjects raw telemetry to preliminary editing, filtering, or transformations. Thus, 
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SOURCE PACKET (Fig, i-2) 
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the Onboard Information Processor alters the information content of data, and is not 
a function geared towards data tra' sport. Since some experiments may require very 
I"ecise time registration, and since the transformations or other processing 
performed by the Onboard Information Processor may introduce indeterminate time 
delays, it is necessary to merge the time and telemetry data streams immediately at 
the Onboard Informatoin Processor input port. All the instruments on the spacecraft 
may share the same Onboard Information Processor, or each may have its own. 

The workspace used by packet-forming logic is a "packet buffer". Since 
the frame-forming logic must be prevented from reading a buffer while the packet- 
forming logic Is writing into it, dual buffers are usually required for each instrument. 
(The exception to this is the case where the instrument can fill a buffer and then wait 
for the buffer to be emptied prior to beginning to fill it again.) The mechanism for 
managing these dual buffers is similar to that for controlling the "ping-pong" buffers 
used in some conventional telemetry systems, since the reading function and the 
writing function are alternately switched between the two buffers. However, buffer 
control for packet telemetry is slightly more complicated. This is because it may not 
always be possible to guarantee that the frame-forming logic will be finished reading 
from its packet buffer at the same time as the packet-forming logic is finished 
writing into its packet buffer, The read/write channels must not be switched until 
both functions using the packet buffers release them. This is unlike the highly 
synchronized situation in some conventional telemetry systems, where the read/write 
time intervals are fixed for a particular telemetry format. 

Since the packet-forming processes for all the instruments are 
Independent of each other, it is likely that there may be several buffers 
simultaneously holding completed packets waiting for downlink. Sequential merging 
of packets into the downlink is accomplished by the Queuing and Packet Selection 
logic. There are at least two different ways for this function to obtain information 
about which packet buffers contain completed packets ready for downlink. In one 
approach, the packet buffer control functions are given the responsibility for actively 
informing the packet selection function that a packet is ready. This method can be 
particularly efficient when packets appear infrequently. Another approach is for the 
packet selection function to actively poll each of the buffer control functions for a 
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Packet Ready indication. If data from some instruments are more urgent than from 
others, this can be reflected in the polling schedule by polling some instruments more 
frequently. 

Whichever approach is used, Packet Ready indications will probably be 
written into a table or queue. This table can be periodically scanned by the packet 
selection logic. The use of this logic provides a major advantage of packet 
telemetry; instrument date .an be downlinked only when necess?/y. If an 
instrument's controller decides that nothing interesting is being observed by that 
instrument, no packet will be created and therefore no downlink bandwidth will be 
wasted. When packets do appear, they are downlinked in their turn. Thus, downlink 
bandwidth can be allocated adaptively among the instruments on board on the basis of 
their current data transfer requirements by the queuing and packet selection logic, 

2.2.2 Space-to-Ground Link 

Within the spacecraft, transport frames are passed to a communications 
device which converts them to radio signals for transmission to earth. Transmission 
may be directly from the spacecraft to the ground station, or it may go through the 
Tracking and Data Relay Satellite Sys :em (TDRSS). Telemetry packets are viewed by 
space- ‘o-earth transmission processes merely as a stream of bits requiring reliable 
transpyrt. The processes are therefore transparent to packets. At the receiver, bit 
synchronization and transport frame synchronization retain the traditional roles of 
locating bit and bit field boundaries. 

Due to the use of fixed transport frame lengths the receiver enjoys the 
advantages of a sync pattern appearing at a known fixed interval. The output of the 
space-to-ground segment is a sequence of synchronized transport frames. 

2.2.3 Ground-Based ? iv .uients 

Once transport frames have been received on the ground, source packets 
must be re-assembled, accounted for, and sent on their way to the end users. These 
functions are performed by the Data Staging Facility and the Data Transmission 
Network (Figure 2-5). 

Packet re-assembly is achieved lising information contained in the 
trai sport frame headers. If segments of a long packet have been embedded within a 
sequence of transport frames, the SEGMENT NUMBER COUNT fields in the headers 
of those frames permits the successive reconstitution of the original packet. At the 
end of the packet re-assembly process,the transport frame protocol has been stripped 
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away, and a stream of whole packets is produced. This process is accomplished 
automatically under computer control by a facility which may be shared by many 
missions. The adherence by those missions to format standards permits this 
generalized facility to successfully and Inexpensively process their telemetry. 

In spite of the use of error control measures, packets with bit errors or • 

missing segments are certain to appear. The disposition of such packets is a matter 
of mission policy. Sorric experimenters may wish to see packets even if they are 
known to contain errors. Such packets would be flagged and sent on. If erroneous 
packets are not desired, they would be logged and then discarded. 

Other data staging functions may be performed at the ground station, or 
at some other centralized or decentralized NASA facility. In the latter case, a data 
communication network must provide an online connection between the ground 
station and the other facility. Data staging may include the following functions: 

0 Provision of a short term (approximately ^f8 hours) 
data base, 

o Reversal of bits received from playback of a spaceborne 
tape recorder, 

0 Deletion of redundant data. 

0 Conversion of incoming data rate to match capacity 
of the out-going data transmission network. 

0 Conversion of data cataloging from a mission/data 
acquisition session basis to a user's time line basis. 

0 Sorting of incoming telemetry packets into individual 
instrument data sets. 

0 Creation of user data sets which may include telemetry 
packets for a specialized user, accounting and quality 
control Information, and possibly copies of other user's 
telemetry packets. 

0 Identification of "holes" in data sets caused by missing 

packets. [ 

"Store and Forward" may be a mode of operation in data staging for some | 
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missions. Packets are gathered from the data acquisition network, some or all of the 
functions listed above are performed, and periodically, by an agreed-to schedule, the 
user d'^ta sets are genoMted and output to the data transmission network. 

Another responsibility of data staging relates to the transmission bf data 
sets to their end consumers. It is likely that many of these users will require an 
online connection to data staging. The communications network providing such 
connections will establish a node ID for each user. Since the Mission ID and Source 
ID in the header of a telemetry packet would be meaningless to this network, data 
staging must maintain a table indicating which users are to receive data sets from 
which instrument. The table will be a set of correspondences between Mission/Source 
ID'S and node ID's. As data staging turns over each data set (and perhaps multiple 
copies of a data set) to the data transmission newtork, it must affix a destination 
code which is understandable by the network. This process is accomplished 
automatically. 

Online connections are required between the ground station and the Data 
Staging Facility, and also between the Data Staging Facility and primary destinations 
of data sets. The types of links selected, be they wire, terrestrial microwave or 
domestic communications satellite, correspond to the particular data transfer 
requirements of each connection. These links may be leased lines, commercial (value 
added) networks or a combination during peak traffic periods or for direct 
transmission to smaller users. To the extent feasible, this network will employ 
packet switching under international standard protocols such as X.25. In cases of 
very high bit rates, circuit switching may be employed instead. 

It is important to distinguish between telemetry packets and 
communications packets. Just as the transport frame format is optimized for 
conditions encountered in the downlink, communications packets are optimized for a 
terrestrial network, A sequence of telemetry packets i.s viewed by the terrestrial 
network merely as a bit stream requiring transport. This stream Will be segmented in 
an arbitrary manner, placed into communications packets, carried to the destination, 
and re-assembled into its original form. Since the packet switching network is self- 
managed and accomplishes its own routing and error control, it is transparent to its 
users. 

It is also important to distinguish between primary data sinks and other 
sinks. Primary data sinks are data bases, control centers and certain online real-time 
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users. Dissemination of data products from these primary sinks to other consumers is 
accomplished by a data distributior .letwork. Tr is recognized that for end users not 
I ving an urgent need for rapid delivery of data, magnetic tapes may be the most 
cost-effective means of data transmission. The packetized format is preserved by 
magnetic tape. 

2.3 CONVERSIO^' . . SPACELAB TO PACKET FORMAT 

It would be straightforward today to design Spacelab to be compatible 
with packet standards. However, the design of both the flight and ground portions of 
the Spacelab data handling system pre-date packet formats by several years. 
Consequently, the issue at this point is how to gain the maximum benefit from 
packetization of Spacelab with an acceptable impact to the tremendous investment 
already made in the existing system. 

The Spacelab data handling system can be divided into two different 
parts: a low data rate section and a high data rate section (Figure 2-7), The low data 
rate section acquires experiment data via Remote Acquisition Units (RAU's) which 
pass the data to the Experiment Computer via a common data bus (See Appendix A 
for a more detailed description.) The RAU's and Experiment Computer perform 
certain non-transparent operations on the data (e.g., analog-to-digital conversion, on 
board di.play, etc.), in addition to multiplexing with housekeeping data for downlink 
on a common channel (the ECIO channel). 

Because of the dual nature of the Spacelab system it was decided to 
divide the study into two phases. The first phase was based on the premise that 
Spacelab must have the capability to packetize all experiment data. In the second 
phase it was assumed that the high rate experiments would be able to packetize their 
own data; consequently, Spacelab would packetize only the low rate data acquired via 
the RAU's. These two pnases resulted in the defintion of two distinct design 
approaches: the so-called "full" system and the "hybrid" system. 

The full system approach assumes that a multi-spacecraft packet data 
handling system already exists on the ground, and that Spacelab is modified to 
interface with it it (Figure 2-8). The modification consists of replacing the High 
Rate Multiplexer" (HRM) with a "High Rate Packet Multiplexer" (HRPM) which 
completely synthesizes packets on board. The HRPM delivers a transport frame 
stream to the downlink which complies totally with Guideline 3.3. On the ground 
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Gommen data pfoeessing facilities handle data packets from Spacelab as well as 
packets from other compatible spacecraft. These facilities perform all necessary 
data handling functions including n'‘a«* at tire'* jisplay for payload monitoring and 
contrt , connections f r* User IGSE, and processing and delivery of data products. 
Opcational costs of the common facilities are billed to individual users (including 
Spacelab) according to a rate schedule of the services rendered. 

The second approach’ ,ie "hybrid" system, assumes that all high data rate 
experiments Torm their own packets and that the existing HRM-HRDM downlink can 
be used as is to relay these packets te the ground, The only modification to the 
Spacelab flight system is the insertion of a "Dedicated Low Rate Packetizer" to 
packetize low rate data entering Spacelab via RAU's (Figure 2-9). On the ground the 
POCC and SLDPF are maintai'^- d intact with the following changes. The POCC Is 
modified to display dat • from packet formats and the SLDPF is modified to interface 
with a common packet data staging and distribution system . 

It should be noted that, as a part of the flight system study, packet data 
formats were defined at the flight/ground system interface for both the full and 
liybrid approaches. This was done so that the flight system could be sufficiently 
defined to prove technical feasibility and permit estimation of the cost of conversion. 
The formats are believed to be reasonable, but they should in no way be considered 
binding upon the ground and expeirment studies. The formats recommended by the 
ground study will be assessed for Impact upon flight system and KSC costs, and if 
warranted, the cost estimates adjusted accordingly. 
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SECTION 3 
•’ULL SYSTEM 


3.1 OVERVIEW 


This seetion briefly describes the fuli packet data system for Spacelab, 
the design rationaiei an*^ lie estimated developtrient scheduie. Cost data are 
provided in Section 5. The fuli system concept was first presented at the Packet 
Data Conference held at the Marshall Space Flight Center on 21-22 January 1981. As 
a result of that conference the following clarifications and changes were agreed 
upons 

(1) Spacelab will contain no reversing logic for data from 
High Data Rate Recorder (HDRR). 

(2) Transport frame format will contain a time code in 
the "STATUS INSERT" field. 

(3) Multiple length packets are permitted on high rate 
channels, provided they have valid sync patterns and 
lengths. 

(4) The transport frame length is a mission choice and 
can be any value up to 512 words (8192 bits). 

(5) The HRPM performs ECIO decommutation and packetization. 

Figure 3-1 shows an overall block diagram of the full packet data system. 
All features of the existing system Igure A-3) are retained, with the exception that 
the HRM sampling switch is replaced by the High Rate Packet Multiplexer (HRPM). 
Interfaces to the payload and to the Orbiter are identical. The requirements for the 
HRPM are summarized as follows; 


16 Experiment Channels 
2 Direct Access Channels 

2 CDMS Computer Channels 

3 Voice Channels 
1 PLR Playback 

1 HDRR Playback 


Max Channel rate 16 Mb/s 
Max Channel rate 50 Mb/s 
25,6 Kb/s and 51.2 Kb/s 
128 Kb/s 
1 Mb/s 

2, 4, 8, 12, 16, 2«f, or 32 Mb/s 
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The header is made up of five fields! A 2^-bit synchronization pattern, an 
8-bit "FRAME ID" field, an 8-bit packet segment counter, a 16-bit "FRAME COUNT", 
and a "STATUS INSERT" field. Tl a^.icliioni.-ation pattern is a fixed code for all 
SpacGiab missions, seic*ted to have a good autocorrelation value. The probable 
number is 7512nF# octal, MSB first. 

The "FRAME ID" field is an 8-bit code which identifies Spacelab as the 
originator of the transport fr The ID is assigned by the agency operating the 

ground network responsible for capturing the data, and its primary purpose is to infer 
the format of the transport frame. A secondary purpose for this field is to identify 
the type of data carried by the transport frame; live data, previously recorded data, 
fill bits, or DACH data. The bit positions and codes used for data type identification 
are TBD. 

Tile packet segment counter indicates which segment of the packet is 
contained in the data field of the transport frame and how many segments the packet 
consists of all together. (See subsection 3.2.2 for a discussion of packet 
segmentation). The "FRAME COUNT" field is a modulo 2 counter which increments 
once for each new frame being downlinked. This field is used on the ground to make 
sure that frames are received in the order sent and to detect missing frames. The 
counter together with the time code in the STATUS INSERT is also useful in 
identifying where "FRAMES" previously recorded on board Spacelab should be 
inserted into the live data stream. The "STATUS INSERT" field contains the 
Coordinated Universal Time in IRIG B format at which the frame was output from 
the HRPM for downlinking or recording. 

The "PACKETIZED DATA" field contains source packets or fill bits as 
described in subsections 3.2.2 and 3.^.1 respectively. There are no restrictions on this 
field except that the 24-bit synchronization pattern must not appear periodically 
within the data field. (It is acceptable for it to occasionally appear randomly). A 
16-bit cyclic redundancy code (CRC) can be added at the end of the frame for error 
control if desired. 

The length of the transport frame is set during the planning phase of a 
mission and cannot be changed during the mission. The maximum length is 512 words 
(8192 bits). The data field efficiency for the maximum length frame is 98,4%, as 
shown in Figure 3-3. Shorter frame lengths lower the efficiency. 
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Words 


Words U> 


HEADER 


512 




-l 1- 


PACKETIZED DATA 
1 \ 


E.C 


504 


504 


Data Efficiency ® » 98.4% 


FIGURE 3-3. DATA EFFICIENCY FOR MAXIMUM 
LENGTH TRANSPORT FRAME 


3,2.2 Source Packets 

The source packet format selected for use in the full Spacelab packet 
data system is in full compliance with Guideline 3.3 (See Figure 2-2). 

The length of the source packet can be any integral number of 16-bit 
words allowed by Guideline 3.3, provided it does not require more than 16 transport 
frames. The maximum allowable length of source packet will depend upon the 
transport frame length chosen for the mission. For example, if the maximum frame 
length of 512 v/ords is chosen, the maximum packet length is the usable data field 
length p>er frame (504 words) times the maximum number of frames per packet (16). 
This results in a maximum allowable packet length of 504 x 16 = 8064 words or 
129,024 bits. Table 3-1 lists all the packet lengths allowed by Guideline 3.3 (Table 
3.3.2) which do not exceed 129,024 bits. 

Five types of source packets are produced by Spacelab: Voice packets. 
Subsystem Computer Input/Output (SCIO) utility packets. Experiment Computer 
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Table 3-1. ALLOWABLE SOURCE PACKET 
LENGTHS FOR SPACELAB 


CODE 

lENGTH 

CODE 

lENGTH 

CODE 

lENGTH 

CODE 

lENGTH 

CODE 

lENGTH 

(HEX) 

twos) 

(HEX) 

(WDS) 

(HEX) 

(WDS) 

(HEX) 

(WDS) 

(HEX) 

(WOS) 

00 

8 

28 

48 

48 

192 

68 

768 

88 

3072 

02 

9 

29 

50 

49 

200 

69 

300 

89 

3200 

04 

10 

2A 

52 

4A 

208 

6A 

832 

8A 

3328 

06 

n 

2B 

54 

48 

216 

68 

864 

88 

3456 

08 

12 

2C 

56 

4C 

224 

6C 

096 

8C 

3584 

OA 

13 

20 

53 

40 

232 

60 

928 

80 

3712 

oe 

14 

2E 

60 

4E 

240 

6E 

960 

8E 

3840 

OE 

16 

2F 

62 

4F 

248 

6F 

992 

8F 

3968 

10 

16 

30 

64 

50 

256 

70 

1024 

90 

4096 

n 

17 

31 

68 

51 

272 

71 

1088 

91 

4352 

12 

18 

32 

72 

52 

288 

72 

1152 

92 

4608 

13 

19 

33 

76 

53 

304 

73 

1216 

93 

4864 

14 

20 

34 

80 

54 

320 

74 

1280 

94 

5120 

15 

21 

35 

84 

55 

336 

75 

1344 

95 

5376 

16 

22 

36 

88 

56 

352 

76 

1408 

96 

5632 

17 

23 

37 

92 

57 

368 

77 

1472 

97 

5888 

IB 

24 

38 

96 

58 

384 

78 , 

1536 

98 

6144 

19 

25 

39 

100 

59 

400 

79 

1600 

99 

6400 

lA 

26 

3A 

104 

5A 

416 

7A 

1664 

9A 

6656 

10 

27 

38 

108 

58 

432 

78 

1728 

98 

6912 

1C 

28 

3C 

112 

5C 

448 

7C ’ 

1792 

9C 

7168 

ID 

29 

30 

116 

so 

464 

70 

1856 

90 

7424 

IE 

30 

3E 

120 

5E 

480 

7E 

1920 

9E 

7680 

IF 

31 

3F 

124 

5F 

496 

7F 

1984 

9F 

7936 

20 

32 

40 

128 

60 

512 

BQ 

2048 



21 

34 

41 

136 

61 

544 

81 

2178 



22 

36 

42 

144 

62 

576 

82 

2304 



23 

38 

43 

152 

63 

606 

83 

2432 



24 

40 

44 

160 

64 

640 

84 

256d 



25 

42 

45 

168 

65 

672 

85 

2688 



26 

44 

46 

176 

66 

704 

86 

2816 



27 

46 

47 

184 

67 

736 

87 

2944 




NOTES: 1. Lengths are given in terms of 16-bit words 

2. Length codes are given in 2-digit (8-bit) hexadecimal code. 
The two digits are "E” and "M" respectively in the following 
formula: 

L = (128 + 8M) X 2^ = Packet Length in bits. 
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Input/Output (EClO) utility packets, low rate experiment packets, and high rate 
experiment packets. 

\2,2A Voice Packets 

The HRPM accommodates three analog voice channels coming from the 
Spaceiab Intercom Master Station in the module configuration and, if required, from 
the Orbiter Audio Centra' Controi Unit (ACCU) in paliet-only configurations. A 
voice digitizer converts each analog voice signal to a 32 Kb/s digital signal using 
delta modulation. Each digitizer circuit transmits 4 parallel bits at a sampling 
frequency of 8KHz (Figure 3-4), If a "CHANNEL ON/OFF" control line is in the "ON" 
state, packets are synthesized for that channel and inserted into the packet switch 
queue for downlinking. The packet length is 32,768 bits (length code 80 in Tabie 3-1), 
resuiting in the generation of one packet per second per voice channei. Each voice 
channei produces a packet with a unique Source ID so that voice data Gan be 
distributed to all interested experimenters by the ground distribution network. The 
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Figure 3-4. VOICE PACKET GENERATION 
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secondary header contains only a time tag indicating the time at which the packet 
was synthesized. 

Two features shouid be considered in voice packetization for Spaceiab to 
improve the capabiiity of the present system. They are in-flight changes of Source 
ID, and voice operated keying. The first allows routing of packets to different 
destinations on the ground ar . lunction of the mission timeline, and the latter 
suppresses downlinking of unmodulated packets, 

3.2.2.2 SCIO Utility Packets 

The subsystem computer transfers blocks of 80 words 20 times a second to 
the HRM, completing the 1600 word frame shown in Figure 3-5 once each second. 
When overhead is subtracted there are approximately 1300 words of usable data per 
SCIO frame. The packet length is chosen at 1^72 words (length code 77 in Table 3-1), 
resulting in the generation of one SCIO utility packet each second. 

The SCIO utility packet has a unique source ID which is the same for all 
missions. The secondary header contains a time tag and the Orbiter state vector. 
The packet does not contain error control parity. The positions of variables within 
the SCIO frame and therefore within the source packet data field are mission 
dependent because of mission-to-mission reconfiguration of Spaceiab. 

3.2.2. 3 EClO Utility Packets 

The Experiment Computer transfers a 160-word minor frame 20 times per ‘ 
second to the HRM, completing the 3200 word frame shown in Figure 3-6 once per 
second. The frame can be divided into three parts; Overhead, 200 words; PCMMU 
downlink redundant data, 1100 words; and low rate experiment data, 1900 words. In 
the packet! zed system the ECIO frame is divided into two kinds of packets, the 
PCMMU portion which becomes the ECiO utility packet, and the low rate experiment 
portion which is discussed in the next subsection. A length of 1280 words (length 
code 74 in Table 3-1) is chosen for the ECIO utility packet, resulting in the 
generation of one packet per second. The packet has a unique source ID which 
remains unchanged from mission to mission. The secondary header contains a time 
tag and the Orbiter state vector, and the packet carries no error code. 



28 















































ORIGINAU 
OP POOR QUAUIT 


Us« or ditelosure of lh« d*U htroln *i subjwt to 
tho rmrictfofl o« tM tHio ry* of th<i do<;uM<ot, 


Doc. No. MDC G837X 


3.2.2. 4 Low Rate Experiments 

The low rate experiment Ho p'^rtic”. ul the ECIO is decom mutated and 
encapi .lated into packets of various lengths for the various low rate experiments by 
the HRPM. These packets have unique source ID's and secondary headers. The data 
format is of course mission dependent with the attendant mission unique HRPM 
software, 

^.2.2.5 High Rate Experiments 

The Spacelab packet data handling system offers 16 parallel channels to 
high rate users (16 Mb/s/channel maximum). Each of these channels which Is used in 
a given mission for raw measurement data is allocated a packet length of the user's 
choice from Table 3-1, and a unique source ID. The contents of the secondary header 
and source data fields are at the discretion of the user, within Spacelab constraints. 
Each channel which is used for experiment-originated packets can accept multiple- 
length packets, provided they are separated by sync patterns and have valid lengths, 

3.2.3 Ancillary Data 

The Spacelab Packet Data System synthesizes a secondary header within 
each source packet which it generates, for the purpose of encapsulating ancillary 
data. As a minimum, the secondary header contains a time tag indicating the time at 
which the final data word for that packet was received from the experiment. In 
addition, the user may specify as ancillary data for his packet, any data from the 
SCIO and ECIO, As with the time tag, these additional ancillary data items normally 
are read immediately after the final data word is received from the experiment. A 
certain time skew is inherent in the sampling of ancillary data, and the user should 
take this into account in specifying the sampling order. Parameters not in the 10 
lists cannot be specified as ancillary data. 

The ECIO contains measurement data from low-rate experiments, and in 
some instances an experimenter may desire certain measurements from another 
experiment to be incorporated into his source packets as ancillary data (e.g., the 
horizon detector on Mission 1). This, requirement can be met by the full system from 
a technical standpoint. However, permission to do so must be granted by the owner 
of the instrument generating the data. 

In the case where a sophisticated experiment builds its own packets, the 
experiment is responsible for encapsulation of any required ancillary data. While 
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experiments are provided with time code, the SCIO and ECIO buses are not available 
to experiments. 

A user may speeixy as long as a list of ancillary data as he desires. 
However, he should realize that the more ancillary data he uses the more downlink 
bandwidth he must have in order to downlink the same measurement data rate. The 
Secondary Header format codes and ancillary data format are TBD. 

3,2A Embedding of Source Packets 

Source packets are embedded within transport frames according to the 
following rules, in accordance with Guideline 3.3. A typical sequence of transport 
frames is shown in Figure 3-7. 

1. When the system is ready to downlink a new source 
packet, the "FRAME COUNT" field of the next available 
transport frame is incremented by one and the "SEGMENT 
NO," field is reset. 

2. If the source packet is shorter than the "PACKETIZED 
DATA” field, the remainder of the field is completed 
with the fill bit pattern, such that overall length of 

the transport frame is maintained at the constant presetting 
for the mission. 

3. If the source packet is longer than the "PACKETIZED 
DATA” field, the excess is carried forward to the 
next transport frame and the "SEGMENT NO." counter 
is incremented. This segmentation process is repeated 

until the entire packet has been embedded within consecutive 
transport frames (16 maximum). 

4. When no source packets are available for downlinking, 
the "PACKETIZED DATA” field of each transport 
frame is loaded with the "fill bit pattern". 

5. Transport frames containing consecutive segments 

of a packet must be downlinked consecutively. Other 
transport frames cannot be interleaved until the last 
packet segment has been transmitted. 
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3*2.5 Packet Data Efficiency 

Packet data efficienc' is defined as the percentage of bits In the 
d vnlinked strearr. of transport frames actually devoted to source data (ancillary as 
well as measurement data). This number is dependent upon the transport frame 
length chosen for the mission, the mix of packet lengths and the ratio of fill frames 
to data frames. If we ass"'"" that the transport frame length is 512 words, that all 
packets are the maximum length of 7936 words (code 9F from Table 3- 1) and that 
there are no fill frames, the efficiency may be calculated as follows: 

Useful Data Words 

Efficiency * Total Frame Words 

Packet Length - Packet Overhead 
" Frame Length X Frames/Packet 

7936 - 5 _ 7931 Words 

= 512 X 16 = MWWorEs 

= 96.8% 

3.2.6 Deviations from Guideline 3.3 

The formats outlined in Section 3.2 deviate from Guideline 3.3 to the 
extent shown in Table 3-2. The rationale for these deviations is also given in the 
table. 

3.3 DESIGN DESCRIPTION 

The HRPM utilizes microprocessor (;^P) design concepts to assemble 
asynchronously-arriving input data into standard packet data format and to control 
the downlink sequencing of completed packets. Although various logic units exercise 
some memory sequencing autonomy, the overall implementation is that of the muiti- 
micro processor configuration shown in Figure 3-8. The input channels labeled SCIO 
and ECIO are flexible CDMS computer to HRPM links. Initial Program Load (IPL), 
operating time, HRPM commands, subsystem status, RAU derived experiment data 
and Orbiter GPC via EC data are examples of the transfers. 

The other inputs do not require the extensive processing associated with 
the computer link. However, each channel has its own asynchronous serial-to-parallel 
interface. Parallel data bus transfers route data between a channel interface, its 
assigned packet buffer and the bit serializer, upon control processor command. 
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Figure 3-8. DESIGN IMPLEMENTATION, HIGH RATE PACKET MULTIPLEXER 
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Table 3-2. DEVIATIONS FROM GUIDELINE 3.3 


OEVJlATinN 


0 PAC KET FORM AT 
» NO DEVIATION 


0 T RANSPOBT THAME rOBHAT 

* "DATA TYPE" PUfiS AOOEO TO 
"TRANSMIT HOOE ID" FltlO. 

NAME ''HAH3CO. 

• “FRAME SEQUENCE COUNT" 

IS INCREASED TO 24 BITS. 


• “FRAME FORKAT" FIELD DELETED. 


RATIONALE 


. PERMITS DETECTION OF LIVE, RECORDED ANO FILL DATA 
FOR MORE EFFICIENT QROUNO PROCESSINO. 

. COUNTER RECYCLES LESS OFTEN MAKING IT EASIER TO FIND 
HORR OVERLAPS. 


. NOT NEEDED IN SPACELAB BECAUSE FRAME LENGTH IS FIXED 
THROUGHOUT A MISSION. 


• “SEGMENT NO," FIELD SHOWS TOTAL - NUMBER OF FRAMES IN PACKET IS NEEDED FOR MANIPULATION 

NUMBER OF FRAMES IN PACKET RATHER OF EClO DATA. 

THAN "LAST SEGMENT" FLAG. 


3.3.1 INPUT ManaRement 

Data arriving at an input channel will be sequentially stored in the data 
field of that channel's assigned packet image currently designated for "INPUT". The 
transport frame headeri the packet header and the designated ancillary data will also 
be required, to assemble a complete downlink packet message. The completed 
packet's memory image is then designated for "OUTPUT" and its companion packet 
image changes its designation from "OUTPUT" to "INPUT". When packet images are 
available for downlink, downlink must be accomplished during their OUTPUT 
designation. A memory image of a typical packet as it attains OUTPUT designation 
and is queued for downlink is shown in Figure 3-9. Notice that packet lengths 
requiring multiple transport frames have the transport frame headers residing within 
the packet's memory image. 

3.3.2 OUTPUT Management 

As packet images attain OUTPUT designation they are placed in the 
downlink queue. The lowest downlink queue position always designates a section of 
memory containing an easily identified fill frame. The sole purpose of the fill frame 
is to maintain continuous downlink synchronization in the absence of transmittable 
packets. Fill frames are recognized and discarded at the last downlink synchronizing 
element. 

The higher priority downlink queue positions contain packet transmission 
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Figure 3-9. PACKET IMAGE IN MEMORY 

sequence pointers based on nonninal data rates, packet lengths, and on an adaptive 
algorithm. The adaptive algorithm weights the current polling sequence with recent 
polling history. Sequencing data into the bit serializer output stream at a rate 
capable of maintaining the selected downlink bit rate is accomplished at the highest 
data management priority. All input channels are scheduled or enabled to eliminate 
resource contending with the bit serializer input. Transport headers and packet 
headers are mostly "static" data loaded into HRPM memory at IPL. Sequence count 
fields of the headers will require updating. Ancillary data necessary to compl-^te a 
packet's memory image require more extensive and dynamic data management. 

Ancillary data variables are extracted from the ECIO and SCIO data 
streams and placed in a memory array. The memory array is the shopping list for ail 
ancillary data. Extracting identifiable ancillary variable values from the ECIO 3200- 
word format shown in Figure 3-6 and routing each word (or bit) for the low rate field 
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3 Output ports selectable under program control 
1 GMT Time Code 
0 Plu**, compatible with HRM 
0 Existing Spacelab power 

The HRPM can accept raw measurement data or finished packets from 
the experiments. Packets the experiment channels are merged with those from 
the voice digitizer and the recorders for downlinking or recording. Ancillary data can 
be placed in the packet by the experiment or by the HRPM. The output packet 
stream meets Guideline 3.3, and can be delivered to any KUSP or recorder input port. 

3.2 FORMATS 

3.2.1 Transport Frame 

The format for the transport frame (Figure 3-2) consists of a i 12-bit (2- 
word) header followed by the packetized data field. This format complies with 
Guideline 3.3, but is a minimum overhead format designed explicitly to satisfy 
Spacelab data handling needs, 
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Figure 3-2. SPACELAB MINIMUM OVERHEAD TRANSPORT FRAME 
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tj rr-^poctive (one of typically 20 pairs) INPUT packet image is accomplished by 
the ancillary data processor. 

Pocke* parity i« •i.'r-igned only after all other bits in the packet have 
attained their OUlPUT values. The CRC code can be generated either by 
'Ml. I .'processor software or by an offline bit serializer with a CRC chip. A more 
If iilrd trade study is necessary in order to determine the better method. 

' * ' Tape Recorder Management 

Two of the inputs to the HRPM are playback data from the Spacelab High 
r*at.i Rate Recorder and the Orbiter Payload Recorder. The HRPM is required to 
Kit. rleave playback data with live data, presenting the composite data stream to the 
K I sp (or downlink. 

The HDRR records data whenever the space-to-ground link cannot be 
.MPu. The HDRR is played back in the reverse direction when the downlink is 
IV ulable and is interleaved with live data. Typically the recorder plays back at a 
I'.K-ri higiier bit rate than the live data. On the ground the composite data stream is 
s.nvirated into live and recorded data and the HDRR data is recorded on High Density 
Tape (HOT). The HDT is played back later offline at a slower rate in reverse, and 
• .‘n It IS, the bit stream is in the same order as it came from the source 
experiments. 

When the HDRR is played back on board, the reversed bit stream is loaded 
m'o new transport frames but not into new packets. An identifying flag is set in the 
header of each frame carrying playback data so that ground equipment can strip off 
the "new" transport frames before routing the data to the HDT. In this way the bit 
stream arriving at the HDT on the ground matches that leaving the HDRR on orbit. 

^ Control 

The subsystem computer lO (SCIO) is used for Initial Program Load (IPL) 
ami lor issuing commands to the HPRM. The commands are used to execute Built-In 
Test Equipment (BITE) sequences, request status or memory, select clock rates and 
■ M. nand output routing. 

1 P ackaging 

Three packaging options were considered for the HRPM (Table 3-3), the 
preferred approach being exact replacement of the HRM with a new box which is plug 
' »! pm compiatible. The overriding advantage to this approach is that no 
: ' ations are required to any Spacelab hardware. 
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With this approach the design envelope for the MRPM is identical to that 
. (LWHh 


Recent advancement in the state of the microelectronics art is such that 
the HRPM easily fits within the above constraints, even tliough it contains far more 
storage and logic than the HRM. 

The other packaging options were considered because, from a functional 
standpoint, most of the logic in the HRM can also be used in the HRPM. The 
disadvantage in trying to salvage the HRM circuitry is that it will consume most of 
the available volune and thermal capacity, leaving little for the packetizer. If the 
[•acketizer is put in a new box outside the HRM and the existing HRM modified and 
retained, there may not be enough room in the igloo for the new box. (The CDMS is 
tususeti within a pressurized container called the "igloo" for pallet>only flights. The 
Igloo IS mounted in front of the forward-most pallet in the hard vacuum environment 
of the cargo bay.) The new box probably cannot be put outside the igloo because of 
pin limitations at the feed-through connectors. Consequently, total replacement of 
t'lr HRM appears to be the only practical packaging approach. 
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OPERATIONAL CHARACTERISTICS 
L'f.l HRPM Flight Opera** 

The HRPivl has tlie same operational features as the HRM; 

(1) Outputing of live data to the 2, ^ and 50 Mb/s ports of the 
Orbiter Ku f^->nd Signal Processor (KUSP). 

(2) Outputing of "direct dump" data from either the vSpacelab 
High Data Rate Recorder or the Orbiter Payload Recorder 
to any of the above ports. 

(3) Outputing of live data to either of the above recorders. 

(4) Interleaving of live data with data from either of the above 
recorders for downlinking. 

(5) Outputing of either of the two DACH's to the 50 Mb/s port 
of the KUSP. 

(6) Outputing of either of the two DACH's to the High Data 
Rate Recorder. 

(7) Digitizing of 3 intercom voice channels (creating separate 
voice packets). 

The HRPM can be programmed to deliver a synchronous transport frame 
stream at any rate shown in Table 3-^f. The output rate must be sufficiently high to 
exceed the sum of the average input rates plus packet and transport frame overhead. 
The output bit rate remains constant regardless of fluctuations in packet traffic 
levels. The HRPM accomplishes this by insertion of "fill bits" in all unused transport 
frames. The output bit rate normally is changed only at predetermined times in the 
timeline. Currently, there is no provision in Spacelab to adaptively change bit rates 
to accomodate high data rate experiments when they encounter unpredictable targets 
of opportunity. 

Three types of data may be carried by Spacelab-originated transport 
frames: live, pre-recorded playback and fill bits. A code within the "FRAME ID" 
field indicates which type of data is contained within the data field of each transport 
frame. The most common data type is live data downlinked directly from the High 
Rate Packet Multiplex on board Spacelab, The Spacelab data handling system has the 
capability to record digital data for playback downlinking at a later time. This 
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The Spacelab CDMS provides two "direct access channels" which allow the 
user to bypass the HRM and feed data directly to the Orbiter Ku-Band Signal 
Processor. In the paeketized data system these channels are used to accomodate 
sophisticated users who generate their own transport frames. Although Spacelab 
provides this service, it does not monitor the DACHs or warrant that the transport 
frame format, bit rate, and quality are compatible with packet standards. Obviously 
the sequence numbers of packets entering the system via a DACH will not be 
correlated with those issued to HRPM - originated packets. 

3.4.2 Packet Mix 

The packet mix downlinked by Spacelab in general is a function of both 
the flight configuration and the mission timeline. Two of the packet sources, the 
SCIO and ECIO, are synchronous fixed data rate inputs which operate at 1472 and 
1280 words per second, respectively. For a transport frame of 192 words, this 
translates into 8 transport frames per second for the SCIO and 7 for the ECIO 
(excluding low rate experiment data). When all three intercom voice channels are 
being downlinked (a function of the mission timeline), transport frames are generated 
at the rate of 33 per second. Thus, the fixed synchronous load is 48 frames per 
second. The portion of the HRPM bit rate left over after accomodating the above is 
available for use by the high rate experiment channels, low rate experiments, (on the 
ECIO), and the High Data Rate Recorder (See Table 3-5). It can be seen from the 
table that, when there is no interleaved recorder playback, channel 2 of the KUSP 
can handle up to 600 transport frames per second of high rate experiment data. 
Interleaved playback of the recorder forces use of channel 3 of the KUSP, providing 
data rates of 600 to 14,875 frames per second to the high rate experiments. 

3.4.3 Payload/Mission Planning Function 

The payload/mission planning function for the packet data handling 
system involves some additional aspects beyond the current system. The mission 
manager has the responsibility of assigning "SOURCE ID" numbers to each 
experiment data source from the list of numbers available to the payload. More 
importantly the mission manager must allocate the available packet memory to the 
experiments by selecting the length of packet for each experiment. For example, 
with a 16-bit, 256K packet memory, approximately 50K is preallocated for Spacelab 
overhead. The remainder can be divided among the experiments in whatever way the 
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mission manager sees fit. A general rule of thumb is that the memory allocation 
must be twice the length of the packet for each data source. (It is more for short 
packets.) The total storage capacity of the HRPM is independent of the length of 
transport frame selected. When longer transport frames are used, fewer can be 
stored in packet memory. 

3.5 DEVELOPMENT SCHEDULE 

It is anticipated that the High Rate Packet Multiplexer development 
would be approximately a 33«month program. It is assumed that five units would be 
required! a qualification unit, three flight units and a spare. Also assumed is that 
two sets of special test equipment (STE) will be required to support qualification 
tests and factory tests. The following sections give a more detailed explanation of 
the schedule and the required manloading. The estimated cost is provided in 
Section 5. 

The HRPM development schedule (Figure 3-10) shows the major 
milestones, phasing and approximate manloading on each task. A work breakdown 
structure is shown in Figure 3-11, The first major task is SYSTEM 
ENGINERING/TECHNICAL MANAGEMENT. This is a three-man level effort for the 
first year with two men assigned to the HRPM and one to STE. These individuals 
would develop conceptual designs, write specifications, and conduct the NASA 
reviews. At critical design review (CDR) conclusion, this effort would drop to 2 men, 
one HRPM and one STE. These two individuals would be responsible for overall 
technical management of the program through installation and checkout. 

The next major task is hardware design. This is broken into three main 
areas: electrical design, mechanical design, and microprocessor (application) system 
design. This effort begins immediately after the preliminary requirements review 
(PRR). Betwen PRR and CDR one additional electrical and two additional mechanical 
designers are added to perform the detailed design required at CDR. Two individuals 
will concurrently develop the microprocessor system design. One will be a hardware 
designer and the other a software engineer. After CDR an additional software 
designer/prograrnmer is added until first delivery. 

The HRPM fabrication and checkout task begins immediately after CDR. 
This effort does not require an exotic technological specialist, 
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and the packaging is similar to the existing HRMj single layer PC type cards and a 
back plane. This is a six-man level of effort through delivery of the fourth unit. 

The next major task is the special test equipment development. It is 
assumed that there does not exist any test equipment which could be utilized to 
support factory test and environmental testing, Special test equipment therefore will 
be required, but a large part may be commercially available equipment supplemented 
with tailored interface designs. This effort begins at program start because the STE 
Will be required to support factory checkout of unit iH at app."oximateiy the sixth 
quarter. One man initially develops the required specifications and supports the 
PRR. This increases to two men (one mechanical and one electrical) to support the 
preliminary design review (PDR). The level jumps to five to perform the detailed 
design and fabrication. STE set //I would be delivered to support factory test, and 
set //2 would support qualification tests. 

The qualification testing is assumed to require three to four quarters and 
iS assumed to be active testing. The initial effort required is to develop test plans 
and procedures, and is at a two-man level for one quarter. The level then increases 
to three and four to perform the detailed electromagnetic compatibility (EMC), 
thermal and mechanical testing. Actual testing is estimated to require two or three 
quarters. 

The documentation task begins at PDR and requires three men. This 
effort will be devoted largely to development of assembly drawings, electrical 
schematics and wiring lists. The data output from this initial effort will largely 
constitute the CDR data package. This effort reduces somewhat for the remainder 
of the program, and the outputs would consist of the operational and maintenance 
requirements specification document (OMRSD), design description, operation and 
maintenance manual, and updates to drawings as required. 

The final efforts shown near the bottom of the schedule are configuration 
management and SR(5cQA functions. The configuration management effort is required 
to incorporate all drawings and documents into the Spaceiab configuration 
management system and to maintain configuration control of documentation and 
hardware. The SR&QA functions shown on the schedule begin at PRR and continue 
through delivery of the final unit. This effort is required to perform supporting 
analyses required for CDR and to monitor development of both flight hardware and 
test equipment. 
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3,6 PRELAUNCH GROUNH PROCESSING 

The most signifieant diange which must be made to the prelaunch ground 
processing equipment in order to accomodate the full packet data system is the 
replacement of the HRDM with a "Packet Demultiplexer" (PDM). The Packet 
Demultiplexer is a new development which accepts a serial packetized data stream of 
up to 50 Mb/s as produced by the HRPM. The PDM performs bit synchronization, 
transport frame sync pattern recognition and packet switching to multiple output 
buffers. These buffers store packets from each source ID and clock out the packets 
at the proper bit rates. Separate output ports are provided for HDRR output, ECIO 
and SCIO utility packets, voice packets and analog, low rate experiment data and 
high rate experiment data. 

Figure 3-12 shows the data flow for Level IV and Level III/II ground 
processing at KSC. The shaded blocks are the elements that would be impacted if 
Spacelab were converted to the full packet data configuration. In both levels the 
HRDM is replaced with a PDM. The present PCM Decommutacors are compatible 
with packet protocol and can continue to be used. In Level IV the Computer 
Interfacing Device (CID) Is compatible with packets, but some software modifications 
are necessary in both of the Interdata 832 computers (PCU and ECEP). The HRM I/O 
Test System (HITS) computer software in Level III/II will require similar changes. 

The cost estimate for ground processing given in Section 5 is only for 
development of the PDM. More study is needed to estimate the other costs. 
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SECTION th 
HYBRID SYSTEM 


tiA OVERVIEW 

The hybrid packet data system concept is based on the premise that all 
high data rate experiments (those designed to interface with one of the 16 high rate 
input channels of the HRM) will have their own dedicated experiment processors 
(DEP's). These DEP's either already are programmed or can be reprogrammed to 
produce packet formats. In this scenario the HRM-HRDM downlink path can be 
maintained essentially intact, since it is transparent to the packets. Packets entering 
the HRM input channels on orbit wili emerge from the corresponding HRDM channels 
on the ground unaltered, 

Figure ^-1 shows a functional block diagram of the end-to-end hybrid 
system. The experimenter can route data to the Experiment Computer for on-board 
display and downlinking. He can also route data direct) v to the HRM for downlinking 
via the Orbiter Ku Band Signal Processor to the earth stations at JSC and GSFC. At 
JSC the user can attach his own Instrument Ground Support Equipment (IGSE) to his 
raw data stream via ports within the POCC. He can also display some of his data via 
POCC systems, provided he meets certain format restrictions. 

At GSFC Instrumentation Data Tapes (IDT's) can be created for the User. 
He can also have his data recorded on Computer Compatible Tapes (CCT's) with 
HDRR overlap removed or have it entered in a packet distribution network, provided 
his data is in packet format. 

Low data rate users (those who enter their data into the system via 
RAU's) can obtain some of the same services at JSC and at GSFC. The ECIO data 
stream is decommutated in real time at the POCC, and experiment parameters can 
be displayed. There is also provision for four direct ports to IGSE. At GSFC low rate 
data can be decommutated from the ECIO. 

Two key issues arise in attempting to implement the hybrid concept; 

(1) What format restrictions should be placed on the high 
rate channel user? 

(2) What can be done to facilitate the handling of 
ECIO data? 
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These two questions formed the basis for phase II of the study to define the hybrid 
system. The approadi taken was to answer tlie high rate question first and then apply 
the same format requirements to the decomnutated ECIO. Subsection <1.2 
summarizes the results of the liigh rate format study and the following paragraphs 
along with subsections <1.3 and <i.<l cover the ECIO decommutation problem. 

Four options were Identified for solving the ECIO problem: 

(1) A dedicated on-board packetizer inserted between the 
Experiment Computer and the HRM 

(2) A redesign of the Experiment Computer and its operating 
system to perform the necessary decommutation and 
packetization 

(3) An ECIO/SCIO decommutator and packetizer located on the 
ground (possible derivative of the HITS/ECEP system at KSC) 

(<i) Addition of a low rate pre-muM to the HRM for low rate 
experiment data, along with an operational constraint 
excluding any low rate experiment data from the ECIO which 
requires SLDPF processing. 

Of these, Options 1 and 2 are discussed in subsections <1.3 and <1.<1 
respectively. Option 3 is outside the scope of this study, but is recommended as 
a candidate for further study. (See section 5). Option <1 does not appear as 
attractive as the others unless additional justification for developing a low-rate 
pre-mux is forthcoming. 

<1.2 HIGH RATE DATA FORMATS 

In the context of the hybrid system the format restrictions imposed 
upon the high data rate user are a function of the ground services desired; i.e., 
the more ground services desired, the more restrictive the format. Table 4-1 
illustrates this. If no ground services are desired, or if the experimenter only 
wants his raw data stream routed to his own IGSE, then the only restriction is 
that his instrument not exceed the maximum bit rate expected by the HRM by 
more than one percent, An excessive bit rate causes the HRDM to overflow, 
losing some of his data.' 
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If the experimenter desires recording of his raw data via GFE recorders at 
any ground facility, he must, in addition to the above, guarantee a minimum bit rate 
within one percent of the nominal in order to b» compatible with IDT recorders. This 
restriction applies to the KSC Level !V and prelaunch operations, JSC POCC and 
GSFC SLDPF. As a result of this restriction an experiment producing packets must 
generate an idle pattern when no packets ready for downlinking. This restriction 
negates one of the advantages enjoyed by the lull packet data system; viz, downlink 
bandwidth is allocated to a data source only when it has valid data to downlink. 

The next level of restrictions applies to the situation where the user 
desires post-mission data staging services from the SLDPF. Examples of such 
services are the creation of computer compatible tapes with the HDRR overlaps 
removed and the delivery of source packets via commercial networks. It is projected 
that in the packet era the SLDPF will have been converted to the hybrid 
configuration of Figure 'f-l. In this configuration the SLDPF will require an 
adaptation of the Guideline 3.3 format for any processing of digital data beyond the 
creation of IDT's - hence the format restriction shown in the table. 
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Table 4-1. FORMAT RESTRICTIONS VS. GROUND SERVICES 
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Finally, if the user desires display of some of his data on POCC terminals 
and/or recording on POCC stripchart recorders, he will have to meet the POCC 
minor frame/major frame requirements as well as the bit rate tolerances. Perhaps 
the most profound result of this restriction is that a single channel of the HRM- 
HRDM may have only one length of packet or one fixed packet string (major frame in 
PCM terminology) for any HRM format configuration. 

It can be seen from Table ^f-1 that a user desiring both POCC display and 
SLDPF processing must meet both the minor frame/major frame and the packet 
format requirements. Figure ^-2 shows the minor frame/major frame format required 
for POCC display, as taken from the POCC Format Standard (Appendix B). The 
minor frame can range in length from % to 4096 bits, and the major f'^ame can range 
from 4 to 256 minor frames (224 to 1,048,576 bits). This means thal a high data rate 
source can generate repetitively a fixed string of packets up to 63,488 16-bit words 
in length, using the maximum length minor frame of 4096 bits (256 16-bit words) with 
the 8-word overhead in Figure 3-2. Every minor frame must have a 24-bit sync 
pattern and an 8-bit frame count. 

Figure 4-3 shows a typical example of the re com n ended format for the 
high data rate users of the hybrid system. It is an adaptation of the Guideline 3.3 
format of Figure 2-4 which meets the POCC requirements of Figure 4-2. The 
illustration in Figure 4-3 is a serial bit stream which might be generated by a typical 
experiment and presented to one of the high data rate input channels of the HRM for 
downlinking. In this example the experiment DEP has merged packets of different 
lengths from three different sources (A, B and C) and has embedded them within 
transport frames. This three-packet string is repeated in the same order throughout 
the mission whenever the experiment is sending data. The "FRAME COUNT" and 
"FRAME ID" fields in the transport frame header are interchanged from Guideline 3.3 
to comply with POCC usage. The packet format is in complete compliance with 
Guideline 3.3. 

The bit stream in Figure 4-3 will emerge unchanged from one of the 
HRDM output channels at the SLDPF. It is fed into a "Packet Synchronizer" where 
the transport frames are stripped off. The same bit stream emerging from the 
HRDM at the POCC is interpreted as a minor frame/major frame sequence. The 
minor frame corresponds to the transport frame and in this example the major frame 
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Figure 4-2. POCC FORMAT REQUIREMENTS 
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corresponds to five minor frames. (The major frame can contain up to 256 minor 
frames.) Any variables within the packets or the transport frames can be designated 
for POCC display or stripcharting. The time code in the "STATUS INSERT" field of 
the transport frame is used to drive the time scales of the displays and strlpchart 
recorders at the POCC. 

It can be seen from the foregoing example that it is feasible to satisfy the 
format requirements of both the POCC and Guideline 3.3 simultaneously. The only 
modification necessary at the POCC is a software change to drive the displays and 
strlpchart recorders from the frame "STATUS INSERT" field rather than the present 
time code fields. 

^.3 DEDICATED LOW RATE PACKETIZER 

The first option to decommutating the low rate experiment data is the 
"dedicated low rate packet! zer." The low rate data packetizer is a computer driven, 
dual input/output, special purpose format generator. The hardware design is driven 
by the conflicting concepts of real time display (at the POCC) and packet data 
delivery (at GSFC). This subsection discusses the various system concepts applicable 
to Spacelab data management and presents a microprocessor based implementation 
for a general purpose packet formatter. 

4.3.1 Format Concepts 

Data from Spacelab experiments classified as producing low rate data are 
acquired via RAU under EC/ECOS control. Each acquired data message (less than 32 
words) is assigned downlink positions within the ECIO format based on the triplet 
execution rate (sample frequency). 

This is time division multiplexing at the message/sub-message level. All 
data acquired by each triplet execution must be downlinked before the next execution 
of that triplet. Utilizing this concept the 3200-word ECIO format does not exist as 
an entity within EC memory. An ECIO format occurs serially within the 51.2 Kb/s 
downlink data stream one time per second, as 20 minor frames, each consisting of 160 
words. All downlink formats must retain the repetitive minor frame, major frame 
structure necessary for sync detection by ground systems. 
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The SCIO format is similar to the EClO; however, the subsystem data rate 
is only 25.6 Kb/s and a minor frame is 80 words in length. The formatting task 
becomes one of transposing a time division multiplexed (TDM) data stream at the 
message /sub-message level to a TDM data stream at the multiple message level. 

A typical ECIO packet compatible format could maintain the 160 words 
per minor frame of the current format; however, 240 minor frames occurring over a 
12 second interval would be required to complete a typical format (major frame). 
The minor frame length must be less than 512 words (16 bits each) with the total 
format not exceeding 256 minor frames in order to meet POCC requirements 
(Appendix C). A packet compatible major frame as shown in Figure 4-4 would 
contain in the data field 8 minor frames dedicated as an EC utility packet and 232 
minor frames available for low rate experiment packets. Each low rate experiment 
ID must be assigned at least one minor frame per major frame (maximum packet 
length 156 words per minor frame) and may be assigned additional sequential minor 
frames as required to encapsulate a packet. Assuming 20 low rate experiment ID's, 
the average packet length could approach 1800 words of 16 bits each with a maximum 
possible packet length approaching 36,000 words. The actual format would be of 
composite structure to maintain features of the current format (POCC compatible) 
while incorporating a packet (GSFC) precursor. 

Consider the composite format shown in Figure 4-5. The format retains 
the 24 bit sync pattern, frame count and auxiliary data field of the current ECIO. 
The functional capabilities of these fields are very similar to the functions associated 
with the transport frame of Guideline 3.3. The remaining unassigned sequential 
words of each minor frame contain sequentially a packet or for long packets a 
segment of a packet. The packet data fields are not restricted to a particular packet 
or non-packet format; however, all experiment user ID sequences begin as a sync in 
the fifth minor frame word. The composite format consisting of 240 minor frames of 
160 words each can be decommutated by standard telemetry hardware to yield a 
serial packet data stream with sync packet delimiters. 

4.3.2 Downlink Options 

A data flow diagram for the composite format and for two alternative 
concepts is shown in Figure 4-6. The EXTRA CHANNEL and the COMBINED lO seek 
to solve conflicting format requirements by keeping the current format while adding 
a packet format. 
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Utilization of an HRM high rate channel to downlink unpacketized format 
for POCC use while simultaneously transmitting the packetized ECIO and SCIO data 
has been suggested. The concept suffers from requiring increased downlink 
bandwidth to transmit the extra copy. All multiple copy concepts increase the 
already severe constraints on the experiment timeline during periods of analog/video 
activity, 

4.3.3 Hardware Description 

The low rate packetizer utilizes microprocessor design concepts to 
assemble ECIO and SCIO serial data streams into a packet data format and to control 
the downlink sequencing of completed packets. (See Figure 4-7.) The input channels 
labeled ECIO and SCIO are CDMS computer interface links. The ECIO contains 
downlink data only: however, the SCIO issues eommands to and receives responses 
from the HRM in addition to its downlink transfers. The packet processor Is designed 
to be transparent to HRM commands and responses. 

Experiment data arriving at an input channel will be stored sequentially in 
the packet memory image data field assigned to that experiment ID. Sync detector 
logic will allow experimenters to initialize their respective ID packet buffer load 
addresses if they so desire. Other input data will be routed to either the EC utility 
packet image or the SC utility packet image. Concurrently any variable from either 
input channel designated as ancillary data will also be written into the ancillary data 
buffer. 

The ancillary dw required for each pjacket is routed to each experiment 
ID and then each completed packet is sequenced to its respective output port in a 
fixed, premission defined progression. A completed progression has sequenced a 
composite format (major frame) to the HRM's ECIO port and has also sequenced a 
SCIO utility packet to the HRM's SCIO port. 

The packet processor software system will consist of a mission 
independent resident program and of mission dependent software driven tables. 
Current mission operations plans will not require changing driver tables during a 
mission. 

4.3.4 Performance Considerations 

The real time data display mission of the POCC is degraded by the data 
buffering so fundamental to packet data systems. The selection of packet lengths 
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and the number of low rate experiment ID's being supported will determine the 
additional data display delay; however, a nominal 9-11 seconds should be anticipated. 

The data processing/routing mission of GSFC is inherently a packet 
concept. The performance benefit GSFC will derive is limited primarily by the 
availability of the ancillary data during the packet! zing process. In the Spacelab 
flight packetizer design only data within the EC/SC environment may be selected as 
ancillary data, Guidance and IPS state vectors are routinely included in the available 
data. 

Placing multiple copies of ancillary data in the downlink reduces, by an 
equal amount, the downlink bandwidth available for experiment data. If each of the 
20 ID'S requested GN<5cC data one time per second, the maximum composite 
experiment data rate would be reduced by approximately 17 Kb/s. 

The ECIO <Sc SCIO data inputs to the packetizer are currently available at 
the HRDM output. The concept presented for onboard paeketizing could be adapted 
to the GSFC HRDM output to obtain additional benefits; 

1) Packetizer would not have to be flight qualified 

2) No flight weight penalty 

3) No downlink bandpass penalty for ancillary data copies 
a) No verification of flight software. 

4.4 LOW RATE PACKETIZATION VIA EC/ECOS REDESIGN 

The second option of decommutating low rate experiment data is by 
means of modifying the Experiment Computer and its software. 

Paeketizing low rate data within th Experiment Computer will require 
ECOS to perform additional buffer, format and ancillary data management functions. 
Data from each experiment ID would be buffered to packet length and output in 
packet format with ancillary data encapsulated. The implementation would maintain 
the current General Measurement List (GML) data acquisition concept and ECOS 
onboard services; however the following areas would have major impact; 
o GML dependent output processing by ECOS 

o EC Memory 

0 CPU Utilization 

o Support Software, 
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Data routing within the CDMS is GML derived. A GML-triggered 
acquisition triplet to an experiment ID results in a data message of up to 32 words 
being stored in a buffer specifically dedicated to that acquisition triplet. The next 
execution of that acquisition triplet writes into the same buffer locations; therefore 
output triplets write the data into the output format between acquisition triplet 
sequences. To generate a packet data ECIO format this input-to-output pipeline 
must be interrupted by extensive packet length data buffers for each experiment ID. 
Approximately 50% of ECOS must be modified in order to provide output processing 
compatible with a specified packet format. 

itA.2 EC Memory 

Support for twenty packet ID'S wouid require approximately 4K memory 
words for data buffering. Additional ECOS software routines to perform buffer, 
format and ancillary data management would require between 3K and itK for 
instruction storage. The EC configuration Is already memory critical; therefore 
packet data cannot be implemented without expanding the available memory. 
Expansion of the memory requires replacement of the present memory cards with the 
more compact 13-mil core type, which must be flight qualified. In addition the 
addressing scheme of the 10 Unit is limited to 6W, necessitating redesign for 
expanded memory. 

An additional concern is the impact that expanding the experiment 
computer memory would have on CDMS computer redundancy management. As a 
minimum the CDMS backup computer would require the same expansion. 

^>.4.3 CPU Utilization 

Execution of the additional ECOS routines required to support 
packetization within EC/ECOS is estimated at 25% of CPU capability. The current 
ECOS CPU allocation (34%) and ECAS CPU allocation (66%) cannot be reduced 
without impacting Spacelab support services. 

4.4.4 Support Software 

Flight software is structured to be driven by Support Software derived 
tables. Modification of the GML dependent output triplet execution sequencing 
within ECOS will result in 45% modification of the CDMS Analysis Support Software 
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(CASS) table generation routines, A CASS expansion estimated near 25% is required 
to generate new packet dependent ECOS driven tables. Modification to various 
software development facilities will increase the impact to support software to near 
75%. 




Summary 

num iii iji iiiiii i i j i j iii ,u < • 


Low rate packetization by EC/ECOS modification is not technically 
feasible. The reason is that the present computer is fully utilized in terms of both 
speed and memory. The entire EC would have to be replaced with more advanced 
hardware. This in turn would require rewrite of a largo amount of flight and ground 
software 


PRELAUNCH GROUND PROCESSING 

The Hybrid implementation will require modification of all KSC G5E 
which cheeks, displays or simulates a Subsystem (SCIO) or Experiment (ECIO) 
computer downlink format. This type activity Is the primary function of the shaded 
ground support equipment computers shown in Figure ^f»8. The 20 minor frame per 
format applications software residing in the three computes (shown shaded) must be 
changed to process the 240 minor frames per format used in the Hybrid (composite) 
implementation. No hardware impacts have been identified. 
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Figure 4-8. PRELAUNCH GROUND PROCESSING, HYBRID SYSTEM 
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SECTION 5 
CONCLUSIONS 

5.1 FLIGHT SYSTEM IMPLEMENTATION 

Three major conclusions can be drawn from the flight system study; 

1. It is technically feasible to fully packetize all measurement data on 
board Spacelab. However, implementation requires replacement of 
the High Rate Multiplexer with a "High Rate Packet Multiplexer" 
(Full System). 

2. It is also feasible to packetize only the low rate data on board by 
the addition of a "Dedicated Low Rate Packetizer" (Hybrid System). 

3. There is a significant savings in flight system cost if the low rate 
packetizer approach is selected (with the high rate data packetized 
by the experiments). 

5.2 ALTERNATE IMPLEMENTATION 

It appears feasible to mechanize the Low Rate Packetizer in the ground 
data handling system (Minimum Impact System). 

There is no cost to the flight system at all if the dedicated low rate 
packetizer can be implemented in the operational ground based data handling system 
rather than on board. Such an implementation is technically feasible because the 
HRM/HRDM downlink is designed to be transparent. Ground implementation avoids 
the cost of flignt qualification testing, and requires only one operational ground unit 
(at GSFC) as opposed to three flight units. A further advantage lies in the fact that 
there is no weight, volume or power penalty to Spacelab. 

There is a strong probability that the IBM-developed HITS/ECEP software 
used In Level IV Payload Checkout and Level III/II Spacelab integration can be 
adapted to pei .orm the decommutation and packetization functions required in the 
Minimum Impact System. If so, the same mission-unique software package required 
for payload checkout could also be used at the SLDPF for mission 
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operations ECIO data processing. A follow-on study is 

recommended to ascertain the feasibility and estimate the cost of the minimum 
impact approach. 

5.3 COST ANALYSIS 

The results of the cost analysis are summarized in Table 5-1 for three 
approaches to Spacelab packetization. All cost figures are crude estimates based on 
the initial definition of requirements. Only the Spacelab and associated GSE and 
prelaunch costs are estimated, Estimation of the costs of converting the 
experiments, POCC facility and SLDPF to packets are outside the scope of this study 
and must be added to obtain total cost estimates. Flight system costs are for 
delivery of three space qualified flight units plus one spare and one qualification test 
unit. The costs of integrating the flight unit into Spacelab and incorporating its 
documentation into the Spacelab configuration management system are included. 

The "KSC Prelaunch" cost estimate for the Full System is for the 
development of a 50 Mb/s packet demultiplexer to replace the HRDM. This figure 
was obtained by proportioning the HRPM development cost to the HRM-to-HRDM 
cost. If the full system were actually implemented, it is likely that the POCC and 
SLDPF would pay for the development of an operational packet demultiplexer. KSC 
could then purchase an additional unit "off-the-shelf" at a considerable cost saving. 
Hybrid system costs at KSC are largely for software modifications to the Level IV 
PCU/ECEP and to the Level III/II HITS software to accept packetized data from the 
ECIO and SCIO outputs of the HRDM. 

The Minimum Impact Approach uses the flight hardware and software as 
is, resulting in essentiai’y zero flight system cost, as shown in Table 5-1. There may 
be some KSC costs, depending upon the degree of sophistication at the SLDPF. If a 
dedicated low rate packetizer is installed in the SLDPF, it may be desirable to 
modify the HITS/ECEP software at KSC to allow the experimenter to see how his 
data stream will look at the SLDPF during mission operations. Further study is 
needed before a specific recommendation can be made and the attendant cost 
estimated. 
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Table 5-1. COST ANALYSIS SUMimY 
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APPENDIX A 

CURRENT SPACELAB DATA HANDLING SYSTEM 
A.l GENERAL 

The Command and Data Management Subsystem (CDMS) is the control 
element of the Spacelab command and data flow. Figure A-1 provides an overview of 
the CDMS with respect to the Orbiter and other Spacelab elements. 

The primary role of the CDMS is to provide processing functions, services, 
and electrical interfaces to the various Spacelab experiments. The CDMS hardware 
and software provides the following basic services to the Spacelab experiments and 
subsystems: 

0 Data acquisition and transmission 
o Data processing 

0 Data display 

o Activation, command, and control of experiments 
o Timing for sequencing/data correlation 
0 Analog data acquisition 

o Closed circuit television 

0 Audio communication 

o Utility support services (control, monitoring & power). 

The following subsections describe the hardware, software, experiment 
data acquisition, and payload services characteristics of CDMS. 

A.2 HARDWARE DESCRIPTION 

The CDMS functionally consists of a Subsystem Data Bus, an Experiment 
Data Bus and a High Rate Multiplexer (HRM) subsystem. A block diagram is shown in 
Figure A- 2. The Data Bus System contains three identical computers: an Experiment 
Computer (EC), a Subsystem Computer (SC), and a Back-Up Computer. The EC and 
SC share the Mass Memory Unit (MMU) and Keyboard/Display system. The Back-Up 
Computer is primarily intended as a back-up for the SC and normally contains SC 
programs; however, it can also serve as the experiment controller in the event of EC 
failure, by loading EC software from the MMU. 
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Figure A-1 . COMMAND AND DATA MANAGEMENT SUBSYSTEM 
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The SC provides control and monitoring of the Spacelab subsystems. This 
includes powering up the EC and its associated components and monitoring the 
health/status of these devices in its role as the total Spacelab controller. In addition, 
the SC performs two essential functions with respect to science instrument 
operations. First, it controls the formatting and routing of high rate science data via 
the HRM. Secondly, it performs the monitoring and top level control of the 
Instrument Pointing System (IPS). 

The experiment data management components (computer, I/O Unit, data 
bus, and RAU modules) are identical to those in the subsystem data management 
components with the exception of the User Time Clock (UTC) capability, which is 
unique for experiments. 

A.2.1 Computers 

The CDMS contains three identical 125 MS computers designed for real- 
time data processing under severe environmental conditions. The computer has a 
Fast Arithmetic Operator which provides 200,000 floating point operations per second 
capability. 

The Central Processing Unit (CPU) is microprogram controlled and 
interfaces with main memory and a Direct Memory Access (DMA) channel which 
provides a maximum transfer rate of 700K words/second. The CPU interfaces with a 
peripheral bus (the Minibus), an interrupt system, and a microprogram suspension 
system which controls input/output. The Minibus is used for the checkout or 
attachment of various ground peripherals. Summary features of the CPU and its 
input/output capability are as follows: 

Microprogrammed with built-in Fast Arithmetic Operator (FAO) 
and direct access memory channel 

Addressing capacity: IM Bytes (512 K words) 

Arithmetic: binary, 2's complement 

Fast registers: 256 16-bit 

Hierarchical interrupt system' 32 levels 

Variable data representation: binary, fixed point, floating point, 
character (byte) string 
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Addressing modes; 13 direct and indirect 

Processing modes; 3.2 x 10^ operations/second (Gibson Mix) 

- Inputs/outputs; 

0 parallel 

0 programmed and DMA 

0 700 K words/sec (DMA) 

- Memory; 

0 Core 

0 18'bit words (16 data-bits, 1 protection-bit, and 1 parity-bit) 

0 Access; byte, word, or double word 

0 Capacity; 64 K words. 

A.2.2 Input/Output Unit lOU 

All communications between the computers and the rest of the CDMS are 
handled by the lOUs. They control the transfer of external data into the computer 
memory and the transfer of data from the memory to all peripherals. The lOU has 
three interfaces with the rest of the CDMS: (1) RAU and HRM, (2) Digital Display 
Unit (DDU) and Keyboards, and (3) Mass Memory (Figure A-2). It also has three 
interfaces with the Or biter: (1) Multiplexer DeMultiplexer (MDM), (2) PCM Master 
Unit, and (3) Master Time Unit. Each interface is controlled by a "coupler", which is 
attached to the non-redundant internal panllel bus of the lOU. All couplers except 
the "time coupler" are dual-redundant ano communicate with other devices via a 
serial data bus. Only one element of a dual pair is powered at one time. 

The interface between the lOU and the prime (and back-up) computer is 
performed by the redundant DMA coupler. This coupler receives and generates 
control discretes from and to the computer memory interface and receives and 
transmits addresses and data over a 16-bit parallel memory bus. The lOU has priority 
over the CPU memory access and data flow through the lOU is prioritized according 
to a hierarchy. 

A. 2. 3 Mass Memory Unit (MMU) 

The Mass Memory Unjt (MMU) is a reel tape recorder for storage of all 
software for the subsystem and the experiment computers. It enables the CDMS to 
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reload and/or periodically load the computer memories from the MMU. It stores the 
data display skeleton formats and pre/in-fllght stored experiment tables for usage 
within experimenter provided programs, and experiment programs that were not 
contained in the initial prf'gram load. Write protection is implemented by software in 
the MMU handler of the operating system. The user (EGAS) has no control over the 
write protect since it is all contained in EGOS. The summary MMU characteristics 
are as follows: 

0 

Total storage capacity; 1.34 x 10 bits 
Read/write speed; 88 inch/sec (2.2 Mb/s) 

Maximum data transfer rate: 500kb/s 

Bit error rate during MMU life; less than 1 in 10^ bits 

Over 20000 full length tape passes before tape/head wear 

- Access Time; Approximately 60 seconds maximum (end-to-end) 

- 7-h seconds for center positioning of data 

A. 2.4 Data Display System (DPS) 

The DDS is the primary on board man/machine interface for the GDMS. 
It is comprised of the Data Display Unit (DDU) and associated Keyboard (KB). One 
DDS can be mounted in the Gontrol Genter Rack of the Gore Segment and one or two 
in the Orblter Aft Deck. Another DDS may be mounted in the Experiment Segment. 

DDU/KB's are connected to both the subsystem I/O unit and the 
experiment I/O unit by means of redundant display buses similar to the data buses. 
Therefore, each DDU can display information from both computers simulataneously 
and the display format is controlled by software. Each KB can communicate via 
Subsystem Gomputer and Experiment Gomputer by means of a manual switch. Each 
KB has also the ability to call either subsystem or experiment- information for display 
on any of the three DDU's. This is also controlled by software. The major hardware 
characteristics of the DDU are summarized as foliows; 

Buffer memory; 1024 words of 16 bits 

Available symbols; Alphanumeric (128) and Vectors 

Available positions for symbols; 22 lines of 47 symbol positions 

Size of symbols; 4.8 x 3.2 mm or 7.7 x 5.1 mm 

Refreshing rate; 60 Hz nominal, 30 Hz minimum (overload condition) 

Golors: Red, yellow, green, overbright green. 
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The KB produces art ASCII code. There are 115 usable alpha-numeric 
symbols, 102^ different vector lengths, and ff096 different angles. There are a 
limited number of editing facilities for the operator input iine. 

A.2,5 High Rate Multiplexer (HRM) 

The high rate data acquisition on Spaeelab is accompiished by the High 
Rate Assembly which consists of the HRM and the High Data Rate Recorder (HDRR). 
The HRM represents the core of the High Rate Assembly, and its functions extend 
beyond data multiplexing. The HRM also controls the data routing within the on- 
board part of the High Rate Assembly; it performs the voice digitizing and GMT 
encoding, and it provides the electrical interface circuits to the on-board equipment. 
It interfaces with the KU-Band Signal Processor (KUSP) in the Orbiter to accomplish 
the downlink of high rate data. 

The main features of the HRM are; 

Outputs to KUSP; ^8 Mb/s, 32 Mb/s to 125 kb/s in binary steps 
on any of three lines 

Output to High Data Rate Recorder (HDRR); 32-16-8-4-2-1 Mb/s 

Output to Payload Recorder (in Orbiter); 1 Mb/s to 125 kb/s 
(binary steps) 

Input from HDRR; 32-24-16-12-8-4-2 Mb/s 

Input from Payload Recorder; 1 Mb/s 

Experiment Input Channels (16) Nominal Bit Rates; 

at 48 Mb/s HRM output rate 16 Mb/s to 62.5 kb/s 

at 32 Mb/s HRM output rate 15 Mb/s to 41.7 kb/s 

at HRM output rates up to actual output rate 

< 32 Mb/s less the HRM overhead 


Direct Access Channels (2); 50 Mb/s (max) 

CDMS Computer Channels (2); 25.6 kb/s (SC) 

51.2 kb/s (EC) 


GMT Channel resolution for HRM output rates; 
1 Mb/s 10 ms 

1 Mb/s variable, based on output rate 

Voice Channel Inputs (3); 128 kb/s Total 
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A.2.6 Remote Acquisition Unit (RAIJ) 

The RAU's are the principal interfaces between experiments and the 

CDMS for acquisition of low rate digital data, analog data and distribution of 

* 

commands. The data flow between RAU's and the I/O unit is performed via simplex, 
(dedicated) serial buses with 1 Mb/s clock rate. Each experiment RAU provides the 
following capabilities for the user to interface his instrument with the CDMS. 


Inputs; 


Outputs; 


o 128 flexible differential inputs for analog or 
discrete signals 

o ^ serial PCM data channels with clocks, code 
NRZ»L. 

o 6/# ON/OFF command channels 
o 4 Serial PCM command channels with associated 
clocks 

o 4 User Time Clock channels (102^ kHz) 

o li User Time Clock update channels, 4 pulse cycles/s 


The experiment RAU's are connected to the I/O unit by the experiment 
bus, which consists of a unidirectional "command line" that carries instructions and 
data from the I/O unit to the RAU's; and a unidirectional "data line" which carries 
responses and data from RAU's back to the I/O unit. 

Commands and data are transferred in 16-bit words at a 1 Mb/s rate. An 
additional "clock bus" is also provided which distributes the Master Time Unit (MTU) 
derived 1024 kHz clock and update pulses from the I/O unit to experiment RAU's for 
the user. (It should be noted that the subsystem' bus connecting the subsystem RAU's 
to the subsystem I/O unit is similar to the experiment bus except that the "clock bus" 
is not provided.) Experiment RAU's can be connected to the experiment data bus at a 
number of interconnecting stations (IS) in the module and on each pallet segment. 
Each station accommodates two RAU's. 

The RAU data acquisition is based on a software controlled concept. The 
software for Spacelab subsystem data acquisition and control is provided in the 
Subsystem Computer. The software for experiment data acquisition and control is 
provided by the experimenter in accordance with his requirements. Applicable 
portions of the Spacelab software can be used by the eixperimenter. (Refer to 
subsection A.3 for a summary of the CDMS software.) 
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The experiment RAU's are scanned periodically with basic periods o* from 
10 ms to 1 s. Each scan cycle will be initiated and controlled by the Experiment 
Computer software. The experimenters may design their own software to generate 
additional measurement cycles using the operating system task scheduler. This 
scheduler accepts priority levels and queues up experiment software requests for data 
and command transmission. 

A. 2. 7 High Data Rate Recorder 

The principal function of the High Data Rate Recorder (HDRR) is to 
provide for intermediate recording of experiment data during interrupted Orbiter to 
TDRSS transmission times. Besides this, the experimenter may record his experiment 
or housekeeping data for on-board storage, 

The HDRR and the HRM form an integrated system controlled by the 
Subsystem Computer in a coordinated manner. Experiments interface with the 
HDRR via the HRM only. During recording of formatted data and reproducing of all 
data, the HDRR is externally synchronized by the HRM clock. When connected to a 
DACH channel, the HDRR is synchronized to the experimenter clock received via the 
HRM. 

The HDRR is used as a buffer during TDRSS non-coverage time or Ku- 
Band modes with bit rates below the HRM output bit rate. During reproduce the 
recorded data can be interleaved into the real time data stream through a recorder- 
dedicated input channel of the HRM or directly dumped to the KUSP via the HRM, 
but independent of the formatter. The HDRR can play back only in reverse. 

A.3 SOFTWARE DESCRIPTION 

The Spacelab CDMS is controlled by two operating systems, the 
Subsystem Computer Operating System (SCOS) and the Experiment Computer 
Operating System (ECOS), which reside in the respective computers. Experiment 
Computer application programs which are mission unique are referred to as 
Experiment Computer Applications Software (ECAS). 

A.3.1 SCOS 

SCOS software originates commands and monitors performance for 
operation of the Spacelab hardware. The major impact of SCOS to the experiment 
data flow is in powering up/down experiments and in providing HRM format control. 
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Formats selected from the Mass Memory Unit (MMU) are transmitted via Data Bus to 
the HRM where they are executed on SCOS command, A software executing back-up 
capability exists within SCOS for the hardwired Spacelab CW Subsystem. 

A.3.2 ECOS 

The ECOS provides a real-time, multiprogramming operating system to 
perform hardware resources allocation and application program control/support for 
the 125 MS computer. It executes the following functions in performing its role in 
support of experiments; 

- lOU Power Control 

- Interval Time Support 

- I/O Processing 

- Telemetry Execution (out-of-limits) Monitoring 

- Orbi ter M DM Communications 

- Dedicated Experiment Processor Communications 

- Keyboard Processing 

- Display Processing 

Timeline Execution and Maintenance 

Slow Loop Processing Oong duration processor control) 

- Background Processing Control 

ECOS also provides data converjion (numerical, character, string) and 
error recovery (hardware, software) services for all programs executing in the EC. In 
addition it provides a collection of routines available to all EC software tasks. 

A.3.3 ECAS 

The user’s software resident in the Experiment Computer is designated 
Experiment Computer Application Software (ECAS). This software can be written to 
perform virtually any operations upon his data that the user desires, within EC speed 
and memory constraints. The software can be written in FORTRAN or 125 MS 
assembly language. 
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A.4 EXPERIMENT DATA ACQUISITION AND HANDLING 

The current Spacelab data handling system provides two types of paths for 
acquisition of experiment data: (1) the RAU for low rate data, and (2) the HRM for 
high rate data. The flow of experiment data is shown in Figure A-3. 

Low rate data are sampled by Remote Acquisition Units (RAU's) and 
transferred to the EC via interconnecting stations (IS's), the experiment data bus, and 
EC Input/Output Unit (EC lOU). On the same path, serial magnitude commands and 
discrete (on/off) commands are transferred from the EC to the experiment via the 
RAU's. 

Low bit rate scientific and housekeeping data processed by the 
Experiment Computer can be transmitted by the Orbiter downlink via the Tracking 
and Data Relay Satellite System (TDRSS). 

Medium and high rate scientific data are acquired by the High Rate 
Assembly part of the CDMS. This part consists of the High Rate Multiplexer (HRM) 
which includes a Voice Digitizer, the High Data Rate Recorder (HDRR), and the 
Orbiter Payload Recorder. This system is able to multiplex up to 16 experiment input 
channels and data from the SC and EC for direct downlink via the Tracking and Data 
Relay Satellite System or for recording (HDRR or the Orbiter Payload Recorder) 
during non-transmission times of the Orbiter KU-Band System. The recorded data 
may be interleaved with real time experiment data for transmission to ground. 

A.4.1 Low Rate Data Acquisition 

Low rate experiment data resides in user-provided buffers. The RAU 
provides the 1 MHz clock used to transfer a maximum of 32 serial data words to the 
data bus. A 16-bit buffer in the RAU checks word by word parity. 

Data from the RAU traverse the data bus through the I/O units and are 
buffered under control of ECOS. ECOS configures the data as shown in Figure A-4 
for transmission via the data bus to the HRM EC port, The low rate data format is 
transparent to HRM processing when multiplexed with high rate data. 

A. 4.2 High Rate Data Acquiaition 

The user delivering serial data to the HRM will, on the ground, recover his 
data from a High Rate Demultiplexer (HRDM) completely unchanged. This means 
that the user himself has to take care of the formatting and structuring of his se’*ial 
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Figure A-3. CURRENT SPACELAB EXPERIMENT DATA ACQUISITION AND HANDLING SYSTEM 
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Figure A-4. EC FORMAT TO HRM 


data. To facilitate this task, each HRM experiment channel can operate in two 
different modes; 

Normal Mode; 

In this mode, the word structure in the HRM output frames are not at all 
correlated with any structure of the input data. The seriad input data are 
arbitrarily chopped into 16-bit words for parallel processing inside the 
HRM. Consequently, the user has to insert some kind of sync pattern into 
his serial input bit stream, in order to be able to extract on ground his 
scientific data out of the serial bit stream of his output channel. 

Word Pattern Transparency Mode; 

In this mode, the input data can be structured in words that, after 
multiplexing, can be Identified as words in the HRM output frames In 
those positions determined by the chosen format. Synchronously with the 
frame or format pulse, which indicates the beginning of a new frame or 
format respectively, experiment data can be delivered to the HRM in 
bursts of 16-bit words. Because the clock counter is reset at the 
beginning of each format, these words are identical to the internal words 
the HRM handles in parallel. The HRDM in this mode delivers the data 
words without bit rate smoothing at the nominal bit rate allocated to the 
particular experiment channel. 
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The mode of each HRM input channel is selected by an external HRM 
connector. This connector is programmed by hardwired jumpers on a mission-to- 
mission basis. It should be noted that in the word pattern transpapency mode the 
words are delivered as 16-bit bursts and not as a continuous bit stream. This has to 
be taken into account for further on-ground data handling because it might rule out 
the use of standard ground decommutation and recording equipment. 

High rate experiment data is clocked (by the user) into an HRM input 
channel as shown in Figure A-5. The 4- 16 register is reset and a format pulse made 
available to the user each time 16 bits of data are clocked into the the HRM. Four 
words of input buffering are provided for each channel to aid in format building. The 
output format of the HRM is shown in Figure A-6. Alternating SYNC or status 
headers are written into the first two 16-bit word positions of each HRM frame. The 
line words are sequentially transferred to a shift register for serial transmission to 
the KUSP. 

Changing of HRM/HRDM formats requires close time-line coordination 
between onboard and ground-based systems to minimize loss of data to experiments 
not affected by the change. The problem is more complex if an HRM bit rate change 
occurs as a result of the new format. In this case, the configuration of all frequency- 
sensitive components in the data flow (such as hit synchronizers) has to be changed. 
In some cases the operating mode of the KUSP also has to be changed. 

A./t.3 HRM Data Handling Services 

In addition xo the items described in the preceeding subsection, the HRM 
also provides the following services to the payload (Refer to Figure A-3): 

Outputing of multiplexed data stream to the 2, ^ or 50 mb/s ports 
of the KUSP 

Outputing of the multiplexed data stream to either the HDRR or the 
Orbiter Payload Recorder 

Interleaving of reproduced (playback) data from either recorder into 
the live data stream 

Direct dump of either recorder to the KUSP 

Outputing of either Direct Acess Channel (DACH) to the KUSP 

Outputing of either DACH to the HDRR. 
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Figure A-5. HRM DATA FLOW 
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A. 5 PAYLOAD SERVICES 

The CDMS services and interfaces provided to the experimenter are 
essentially the same whether or not the Spacelab Is flown in the Module or Pallet- 
Only configuration. On board, display support in the Pallet-Only mode is provided by 
locating a DDS in the Orbiter Aft Flight Deck. 

Mission unique requirements are accommodated by addition of up to 21 
experiment RAU's, flexibility of HRM data rates, modes, and formats, and mission 
unique software application programs (EGAS). 

ECOS can support up to eight core-resident application programs at one 
time and exchanges (overlays) the programs from the MMU as necessitated by the 
mission timeline. Scheduling of experiments and EGAS can be accomplished by ECOS 
timeline services. 

Ground monitoring of experiments is performed via Experiment 
Computer-acquired low rate data (<5Kb/s) and directly acquired high rate data via 
the HRM/KU jP. Both types of data may be extracted (on the ground) from the KUSP 
50Mb/s composite data stream. Both types are recorded on board during times with 
the downlink is not availaible. 

Direct downlink of high frequency (dc to 4.5 MHz) analog or video signals 
is also provided by the CDMS for experimenter control and real time evaluation. 
Additionally, three voice channels can be digitized and downlinked as part of the 
HRM composite output. 

Experimenter uplink commands from the POCC are routed via the MCC 
and GPC to the CDMS for experiment control, timeline command sequence loads and 
EGAS communication. 

Onboard experimenter control/monitor functions are performed by the on- 
board crew who has access to the displays and keyboards (DDS). In conjunction with 
the DDS, the EC supports the examination of experiment data via experiment-unique 
display pages and the issuing of commands from the alphanumeric and functional 
keyboards. Using the DDS, the experimenter can transfer software from the MMU to 
the EC or to a DEP. 
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Timing is available to the experiments for correlation of data . Mission 
Elapsed Time (MET) from the Orbiter is also provided for the experimenter. Also 
provided are the 102<f kHz User Time Clocks (UTC) with ^ Hz updates. The UTC's 
are routed through the CDMS to the experiment RAU Interface. 

NASA, in conjunction with the experimenter, determines the extent of 
CDMS moni tiring of experiments by the Caution and Warning System. 
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APPENDIX B 

CEOnCE C. ^tARSHALL SPACE FLIGHT CENTER 
. .UAHSHALL SPACE FLIGHT CENTER, ALABAMA 3S812 

'* STANDARD 

? 

PAYLOAD OPERATION'S CONTROL CENTER FORMAT STANDARD 
1.0 PL RP05E AND SCOPE 

This standard defines the characteristics and constraints on telemetry 
formiat structure for those telemetry data streams (or portions of telemetry 
data streams) required to be processed by the Payload Operations Control 
Canter (POCC) at Johnson Space Center. Those e.Nperiments requiring POCC 
' support must meet this Standard. In addition, a set of recommendations for 

optimizing experiment data decommutation and processing is Incorporated In 
the Standard. The user may ignore these recommendations and still be in 
I compliance with the Standard. 

f. Telemetry data streams requiring POCC recording and transmission to 

experiment provided Ground Support Equipment need only to meet the POCC 
telemetry standards for bit rate (paragraph 1. 2. 1) , minor frame length 
1 (paragraph 1.2. 3.b) , and frame synchronization pattern length (parag.raph 

1.2, 3,d). 

^ The characteristics of the bit stream required by the radio linlc are not 

included in this standard because POCC requirements are limited to hamiling 
demodulated, bit synchronized, NRZL data scream and associated clock. 
Standards for error encoding are not included because there are no POCC 
I requirements to perform error decoding. Standards for time tags within the 

' experiment data streams are not included because POCC processing will use 

either the Spacelab's High Rate Demultiplexer (HRDM) time tag or the POCC 
I receipt time tag. 

A composite set of format standards relative to the High Rate Multiple.xer 
’ and ground data processing is contained in the Tpacelab High Rate Multiplexer 

(HRM) Format Standards.” The standard as specified herein imposes some 
more restrictive specifications on the telemetry format structure to allow POCC 
I processing. If those standards are met, the standards specified in the reference 

I document will be met. 

1 i’ 1*1 Definition of Terms — This section provides definitions of telemetry 

‘ terms as used in this standard. 
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(a) Telemetry data stream — A continuous sinsle serial bit stream of 
time division multiplexed data. 

^ • M » 

(b) Format ~ The fjcnoral arransement of the data in a telemetry data 
stream. Each format shall have a pre-established bit rate, frame size, word 
size, commutation sequence, measurement sot and frame overhead (synch- 
ronization pattern, frame counter, experiment identifier, time words, etc.). 
See Figure I. 


(c) Major Frame — Includes more than one minor frame. The length of 
a major frame is defined as the number of minor frames necessary to include 
at least one sample of all measurements for this format. See Figure 1. 


(d) Minor Frame — A recurring fixed integer number of words which 
includes a single synchronization pattern. See- Figure 1. 

(e) Minor Frame Counter — A single binary word which is included in 
each niinor frame to uniquely identify the frames position in the major frame 
sequence. The counter should increment by one-for each new minor frame with 
a starting value of zero for the first minor frame in a major frame. The minor 
frame counter shall occupy the same word position in every minor frame. 

( f) Word — An integral subdivision of the minor frame defining the basic 
package size for measurements for this telemetry data stream. See Figure 1. 

(g) Parameter/Measurement -- A group of contiguous bits less than or 
equal to 64 bits whose pattern represents the value of the data point. 

(h) Syllable — A meastirement whose Jengtli requires two or more words, 
is said to have syllables, A single syllable is equal to a word. An example of 

a multi-syllable measurement might be spacecraft time. 

(I) Commutated data — That data which is sampled nnlv onof* in n minnr 
frame. See Figure 1. 

(j) Super -Commutated data — That data which is sampled mnre than 
nnop in n mfnnr frnTn<», submultiple frame or sub-submultiple frame. See 
Figure 1. 

(k) Subcommutated data — Data which is multiplexed at sample rates 
which arc submultiplcs of the minor frame rate or when several minpr frames 
are roquirGd to generate a complete measurement set. See Figure 1, 
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Major rramtf 
Max lcn5;^\ 

• 256 Minor 
Frame j 



A — Example of normal commutation — one sample In each minor frame, 

3„ — Example of a super com — the time interval between samples and 

B„ and B„, B_, tmd 3 B and B +1 is identical, , 

4 u 3 4 n n 

Ci D ~ Examples of a subcom — C and D have le^s than one sample per minor 
frame. . 

E„ — Example of super commutation a subcom — the-time interval between 
samples E^ and E^ and E^ and E^ - . . . EN-1 and are identical. 


Figure 1 


^ '1,2 Telemetry Standards •— Telemetry data streams (PCM data) shall be 

transmitted as serial binary-code time division multiplexed samples, using a 
sequence of bits within each sample to represent a discrete magnitude of the 
data samples. This standard defines the allowable data format (including the 
word, minor frame and major frame characteristics) and structure of the data 
to be displayed and processed in the POCC, 
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1.2.1 nit Rnu* — The telemetry data streams to be jprneess.ed by the POCC 
shall be ijroutcr than 2UU bits sec and loss than or equal to 2 Mcgabits/soc. 

Routed telemetry data streams In the POCC shall be jjrcater than 200 
bps and less than 30 Mbps. The telemetry data streams to be recorded by the 
POCC shall not exceed 30 Mbps and the minimum data rate shall not bo less than 
200 bps. Variations oC the telemetry data stream clock rate shall not exceed 
2.3 percent of the normal rate during any processing period. 

1.2.2 Format Ptnicturo — The measurements on each telemetry data stream 
shall be organized into an indentifiable format. Each format shall have a pre- 
established bit rate, a pre-established commutation sequence of a pre- 
established measurement set and identification bits (synchronization pattern, 
frame counter, etc. ) . 

(a) Format Identification — Each format shall contain a measurement 
which identifies the format being transmitted. All measurements within the 
format shall be unambiguously identified by the use of the format identification, 
the minor frame counter, and established frame commutation sequence (word 
location within the minor frame). All experiments with a multi-bit rate 
capability (identical commutation sequence at a higher or lower bit rate) shall 
Include either a mode ID which uniquely identifies each bit rate or a separate 
bit rate Identification measurement in each major frame. 

It is recommended that each experiment telemetry data stream include 
an experiment identification measurement to insure positive identification of 
data during processing. 

(b) Format Change — It IS reOoHimended that changes between formats 
be effected at a time corresponding to the leading edge of the first minor frame 
sync word belonging to the first major frame which will contain the new format. 
Where format changes occur relatively frequently. It is recommended that error 
protection, such as parity, be provided for the format identifier, to insure 
positive identification of the data. 

1.2.3 Frame Structure The frame overhead ( synchronization pattern, minor 
frame counter, experiment ID, format ID, bit rate ID, command verification, 
spacecraft clock, etc, ) and parameter measurements transmitted in each 
telemetry format shall be further organized into sequences of identifiable digital 
words termed a minor frame. The synchronization pattern and frame counter 
must appear in every minor frame. The other frame overhead may appear as 
infrequently as once per major frame. Refer to Figure H. A. 1. -2. The minor 


frame shall be gubr.ivioctl itun words, besiinmrui wuh the first bit of the frame 
svnchfnmzaiion patii-rn. Measurements sltiiU btj muluple>.e(i so ihfit the 
Ixisinnina of everv measiir<*mcnt is coinciileni with llio word structure. Data 
from dilfcrcnt measurements shall not bo Intorleavotl on a bit-by-bit basis or 
oUicr nnnword oriented basis} however, sinslo-bit on-off indicators may be 
assembled in predetermined order into words for transmission. 

( a) Major Frame Format — The majamum length of a major frame shall 
bo 230 minor frames and the minimum frame length shall be four minor frames. 
For a given format all subcommutator cycle durations shall bo integer sub- 
multiples of the major frame cycle duration, and the phasing of the subcortlmu- 
tators shall be fi.xed and synchronized to the major frame, so that a single minor 
frame counter will unambiguously identify the position of all measurements in 
the major frame format. 


of bit i 


(b) Minor Frame Length — Each PCM frame shall contain a fixed number 
, ail of equal dtur-atiotr. Minor frame length is the number ox bits 




appearing between successive occurrences of the leading edge of toe first bit of 
the frame synchronization word. 


(1) The length of each minor frame shall be an Integer multiple of 

8 bits. 


(2) The-minimmn minor frame length shall be at least 4 words after 
toe fianie_3X9chi:(asiz3itiQni^ 


(3) The maximum minor frame length shall be 4096 bits. 

(4) A given format shall use only one minor frame length and one 
word- length. 

(5) It is recommended that unused words within* a format shall be 
distributed so* as to minimize the probability of long sequences of consecutive 
ones or zeros. 


(c) Frame Rate -- The minor frame rate shall not exceed 1024 frames 
per second. 

(d) Frame Synchronization Pattern — Each minor frame shall begin with 
a frame synchronization pattern. The frame synchronization pattern for Space- 
lab shall bo octal 7G5Y1440 and shall appear in the first 24 bits of each minor 
frame. 




(c) rrnme-Soqu&nco M Data -- Tlic format shall be structured so as to 
permit a.mmutncal simer enmmuiaiinn .inplyintf to major ai d minor- frames; 
l.c.t minor or major frame v-orus muat be assianablo to a piven measurement 
so that sumpUna at rofoUarly spac id intervals is possible. (See o.Namples "A” 
and '*E" in Flimre 1.) It is recommended that tlio frame overhead (the minor 
frame counter, cNporimont ID, format ID, command vorilication bit rate ID and 
spacecraft clock) appear at fixed positions immediately following the frame 
synchronization pattern. 

1.2,4 Word Piructure — In those cases whore the PCM telemetry word repre- 
sents a single measurement, the sign bit (if used) shall appear first, followed by 
the magnitude bits in sequential decreasing order, most significant bit (MSB) 
first and ieasi significant bit (LSB) last. 


Sign Data Bits 

( if used) MSB LSB 

. (increasing time) , 


The teiemeory words shall be an integer multiple of S bits in length. 

If multi -syllable words are used, the most sigrificant syllable shall be trans- 
mitted first. It is recommended that miilti -syllable words be placed in con- 
tigpous minor frame word locations. It is recommended that 8-bit words be 
used. Parameter length includes sign bit and magnitude bits, other status bits, 
short length 'registers, and other bilevel measurements shall be grouped 
together into status words whose length is an integer multiple of the telemetry 
word size. There shall be oi^y one word leng^th within a particular" format. 

1.3 Decommutation Limitations — • There are limitations to the number of 

Words that can be extracted from a format which are imposed by the commer- 
cially available decommutation units pfesently baselined for the POCC, The 
limitation is a function of the number of minor frames in a major frame, the 
number of words in a minor frame and the number of subcommutated words to 
be extracted. To avoid or minimize the affect of this limitation, it is 
recommended that subcommutated parameters that are required to be processed 
by the POCC be loaded in the same word(s) in each minor frame. 

!•"* Exceptions •— Each user of the data system shall make every effort to 
conform to these standards. When the c^criment mission requirements cannot 
bo met with a standard system (one that is in complete comformance with these 
standards) , an cxccptioi} may be requested for assessment. 
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( a) The features that arc believed to be nonstandard and the technical 
reasons for their use "-ill be iduntitied. An antiiysis will be provided of the 
system and its operation svith specific reasons why a standard system cannot 
meet the e.%porinionts mission requirements. 

(b) The exception request will be assessed for implementation com- 
patibility, nesultini: costs and/or schedule Impacts will be provided for 
programmatic decisions. 
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APPENDIX D 
ABBREVIATIONS 

ACCU Audio Central Control Unit 

ASCII American National Standard Code for Information 
Interchange 

ATE Automatic Test Equipment 

BI-0 Bi-Phase Logic 

CASS CDMS Analysis Support Software 

C&T Communication & Tracking 

C«JcW Caution <5c Warning 

CDMS Command and Data Management Subsystem 

CDR Critical Design Review 

CD & SC Communications Distribution & Switching Center 

CID Computer Interfacing Device 

CITE Cargo Interface Test Equipment 

CRC Cyclic Redundancy Code 

DACH Direct Access Channel 

DDU Data Display Unit 

DDS Data Display System 

DDSS Data Display System Simulator 

DMA Direct Memory Access 

EC Expe' ‘ment Computer 

ECAS Expf'*.. ^nt Computer Applications Software 

ECEP Experinicnt Computer Equipment Processor 

ECIO Experiment Computer Input/Ouput 

ECOS Experiment Computer Operating System 

ECS Environmental Control System 

EDB Experiment Data Bus 

EMS Electromagnetic Compatibility 

EOF End of Frame 

EPOS Electrical Power Distribution System 
FAO Fast Arithmetic Operator 

FC Frame Count 
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FIFO 

First-In-First -Out 

GFE 

Government Furnished Equipment 

GML 

General Measurements List 

GMT 

Greenwich Mean Time 

GPC 

General Purpose Computer (Orbiter) 

GPU 

Ground Power Unit 

GSE 

Ground Support Equipment 

GSFC 

Goddard Space Flight Center 

HDR 

High Density Recorder 

HDRR 

High Data Rate Recorder 

HITS 

HRM I/O Test System 

HMT 

High Rate Multiplexer Test (Rack) 

HRDM 

High Rate Demultiplexer 

HRM 

High Rate Multiplexer 

HRMTS 

HRM Test Station 

HRPM 

High Rate Packet Multiplexer 

lOU 

Input/Output Unit 

IDT 

Instrumentation Data Tape 

I/F 

Interface 

IPL 

Initial Program Load 

IPS 

Instrument Pointing System 

IRIG 

Inter-Range Instrumentation Group 

IS 

Interconnect Station 

JSC 

Johnson Space Center 

K b/s 

Kilobits per second 

KB 

Keyboard 

KG 

Kilogram 

KSC 

Kennedy Space Center 

KUSP 

Ku Band Signal Processor (Orbiter) 
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KUSP-IS 

KUSP Interface Simulator 

LSB 

Least Significant Bit 

LWH 

Length, Width, Height 

M b/s 

Megabits per second 

MCC 

Mission Control Center 

MDM 

Multiplexer Demultiplexer (Orbiter) 

MDTSCO 

McDonnell Douglas Technical Services Company 

MET 

Mission Elapsed Time 

MILA 

Merritt Island Launch Area 

MS 

Milliseconds 

MSB 

Most Significant Bit 

MSEC 

Marshall Space Flight Center 

MTU 

Master Time Unit 

NASA 

National Aeronautics and Space Administration 

NRZ-L 

Non-Return-to-Zero Logic 

O&C 

Operations <5c Checkout (Building) 

OMRSD 

Operations and Maintenance Requirements 
Specification Document 

OPF 

Orbiter Processing Facility 

PC 

Printed Circuit 

PCM 

Pulse Code Modulation 

PDM 

Packet Demultiplexer 

PCMMU 

PCM Master Unit (Orbiter) 

PCU 

Payload Checkout Unit 

PDM 

Packet Demultiplexer 

PDR 

Preliminary Design Review 

PLR 

Payload Recorder (Orbiter) 

PRR 

Preliminary Requirements Review 

POCC 

Payload Operations Control Center 

RAU 

Remote Aquisition Unit 

ROM 

Rough Order of Magnitude 
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s 

Seconds 

SAM 

System Activation and Monitoring Subsystem 

SC 

Subsystem Computer 

SCIO 

Subsystem Computer Input/Output 

SCOS 

Subsystem Computer Operating System 

SDR 

Signal Distribution Rack 

SL 

Spacelab 

SLDPF 

Spacelab Data Processing Facility 

SPAH 

Spacelab Payload Accomodations Handbook 

SPCDS 

Spacelab Payload Command dc Data System 

SR&QA 

Safety, Reliability and Quality Assurance 

STE 

Special Test Equipment 

TBD 

To Be Determined 

TDRSS 

Tracking and Data Relay Satellite System 

T F/S 

Transport Ficames/per second 

UT 

Unit Tester 

UTC 

Universal Time Clock 

VABR 

Vehicle Assembly Building Repeater 

VDC 

Volts, Direct Current 

,.P 

Microprocessor 
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E.l SUMMARY 

There is no impact to Kennedy Space Center (KSC) facilities 
or operations if either the "Minimum Impact Hybrid" or the "Ground Hybrid" 
version of the Spacelab Packet Data System as defined in Reference 2, 
Appendix C is implemented. This appendix describes the KSC support 
facilities for the Spacelab Command and Data Management System (CDMS) and 
explains why there is no Impact. 

E.2 INTRODUCTION 

Spacelab integration and checkout at KSC emphasizes; 

(1) integration of individual payloads into a total Spacelab 

(2) checkout of a complete Spacelab flight assembly, and; 

(3) integration of the Spacelab flight assembly into 

an Orbiter. 

These activities are referred to as Level IV, III/II and I, respectively. 
The following description is directed to the Spacelab CDMS and to that 
portion of Ground Support Equipment (GSE) which supports CDMS data 
managment during KSC test and integration activities. Figure E-1 shows an 
overview of the facilities under discussion. Summary descriptions of all of 
these facilities are included for completeness. 

The integration process begins in the Operations and Checkout 
(O&C) Building, which houses the Level IV, Level III/II and Cargo Interface 
Test Equipment (CITE) test stands. The fully integrated Spacelab flight 
configuration is transferred to the Orbiter Processing Facility (OFF) for 
integration with the Orbiter. There is a wideband fiber optics link from 
the OPF to the O&C Building for monitoring of the CDMS within the Orbiter 
cargo bay. In addition the Orbiter while in the OPF can communicate with 
the Payload Operations Control Center (POCC) at the Johnson Space Center in 
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Figure E-1. KSC DATA HANDLING SYSTEM 








Houston, Texas. The Ku Band transmitter output goes to an antenna on the 
roof of the OPF and Is radiated to the Merritt Island Launch Area (MILA) 
communications center approximately four miles away. The RF signal is 
amplified and transmitted via the Tracking and Data Relay Satellite System 
(TDRSS) to White Sands, New Mexico, and from there to the POCC. 

There are also re-transmit antennas at each of thu launch 
pads, but their use is not planned, 

E.3 06cC BUILDING OPERATIONS 

A total of five test stands are located in the high bay area 

of the O&C Building, as shown in Figure E-2. High rate and Experiment 

Computer Input/Output (EClO) data can be routed from any of the test stands 
to tliree user rooms located on the fourth floor. Patching of data paths is 

performed in Room 1263 for copper as well as fiber optics lines. Room 1263 

also contains a High Rate Demultiplexer (HRDM) and a High Density Recorder 
(HDR) for use by the Level IV stands. The ECIO data stream can be decommu- 
tated for up to eight simultaneous users by the HRM I/O Test System/Experi- 
ment Checkout Equipment Processor (HITS/ECEP) located in Room 3259, 

E,3,l Level IV Operation 

Level IV accomplishes the functional test and validation ' of 
experiment racks, rack and floor assemblies, and pallets within the flight 
configuration. Experiment flight racks are installed in a level IV test 
stand located at the west end of the high bay area. The experiments are 
connected to test stand-provided flight type Remote Acquisition Units 
(RAU's) and a High Rate Multiplexer (HRM), as shown in Figure E-3, The 
RAU's function as remote terminal units for the 1 Mb/s bi-directional Exper- 
iment Data Bus (EDB), which is connected to the Payload Checkout Unit (PCU) 
in Room 3259, 

The PCU contains a Mitra 125 computer which is the ground 
version of the CDMS 125MS flight computer. The Mitra 125 functions as the 
Experiment Computer for Level IV checkout and executes all of the EC flight 
software. Three remote terminals (DDSS) are connected to the Mitra, one in 
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Uoom 3259 ami two in tho i»igli bay area, Tlie two in the hip,li bay area are 
tised to reprt'sofU the HOSS flight units located in the Orbiter Aft Plight 
ne( k (APn) and tli<* Spat’clab module. In addition the PCM contains an 
)juerdata 8/32 computer winch simulates the remaining intrefaces needed by 
the BC, The PCU provides data to the EC representing data transfers from 
the Orbiter Cicnoral Purpose Computer (GPC), the downlink telemetry (PCMMU), 
Mass Memory Unit (MMU) and Time Unit (GMT). 


The PCU is also connected by a 1 Mb/s bi-directional data bus 
to the Subsystem Computer (SC) port of the HRM. The PCU utilizes this data 
bus to simulate HRM format control commands and status activity normally 
provided by the SC. 


The PCU processor decomrnutates the ECIO data for display '5 
consoles), printing or storage (2 tapes), providing the user his first 
hardware-in-the-loop operation with the Spacelab command and data handling 
systems. 


Low rate data acquired by the RAU's from various experiments 
is transmitted over the EDB to the Mitra 125. The 125 formats experiment 
data and other ancillary data into the ECIO downlink format which is in turn 
transmitted over the EDB to the EC input port on the HRM. High fate 
experiment data goes dirtctly to the HRM from the generating experiment. 

The three HRM output channels are connected to a Ku Band 
Signal Processor Interface Simulator (KUSP-IS) which routes the output to 
the HRDM and High Density Recorder (HDR) (2-50 Mb/s) located in room 1263. 
The output (NRZ-L + clock) from channel 21 of the HRDM, containing the RAU- 
acqulred experiment data (ECIO format), is routed through the Spacelab 
Payloads Command and Data System (SPCDS) to special interfaces with the PCU 
and the Experiment Checkout Equipment Processor (ECEP), ECEP, which shares 
ioom 3259 with the PCU, is an Interdata 8/32 processor programmed to 
simulate the real-time display of ECIO data at the POCC. 

All data and control circuits between Room 3259 and the Level IV 
test stands are provided via the SPCDS distribution patch panels located in 
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Room 12.'*^ Also ECEP data from Room 3259 is available to tl)o user rooms and 
to the SPCDS distribution facility. The user rooms, containing user-pro- 
vided Instrument Ground Support Equipment (IGSE), have access to each HRDM 
output cnannel (NRZ-L + clock @ 16 Mb/s or less) via SPCDS. Multiple, 
flexible and redundant circuits are available between most test elements. 

The ECEP configuration provides KSC Level IV with a simulation of 
.ISC' POCC operation. RAU-acquired experiment data which meets MSFC-STD-630 
(Spacelab High Rate Multiplexer Format Standards) may be displayed during 
Level IV at any of the eight ECEP consoles. HRM channel data not meeting 
.STD-630 must be routed (via SPCDS) to user IGSE within the user rooms for 
processing. 

The HRM I/O Test System (HITS), also a POCC simulator, can be 
configured to support Level IV activities; however its primary function is 
to support HRM testing during Level III/II. (See Section E.3.2), 

E.3.2 Level Ill/U Operation 

Level III/II combines, integrates and checks out all experiment 
mounting elements (e.g. ricks, rack sets and pallet segments) from Level IV 
with the previously installed Spacelab flight subsystem support elements 
G.e,, core segment, igloo). Two Level III/II Spacelab stands are locdted 

just east of the Level IV stands within the high bay area of 06cC Building. 
Operations within Level III/II are based on computer-controlled Automatic 
Test Equipment (ATE) augmented by the Orbitcr Interface Adapter (OIA) and a 
Ground Power Unit (GPU). These elements constitute the Spacelab Electrical 
Ground Support Equipment (EGSE). The EGSE-ATE system, located in Room 3247 
or 3251, issues Orbiter-type commands and processes Spacelab response, ut- 
ilizing the SPCDS distribution terminal. 

The Spacelab under test communicates with the outside world via 
simulated Orblter I/O links, A definition of all the interface signals may 

be found in ICD-2-05301, Appendix B. The high rate data normally downlinked 
via the Orbiter KUSP is routed to a KUSP simulator located adjacent to the 
test stand (Figure E-4). 
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Bacli output channel (50/4/2 Mb/s + clock) from the flight HRM 
mounted in the test stand is connected to the High Rate Multiplexer Test 
Station (HRMTS) iocated adjacent to the stand. The HRMTS contains a KUSP 
Interface Simuiator, HRDM, HRDM Unit Tester (UT), two HDR's and a High Rate 
Muitiplexer Test (HMT) Distributor rack. The HMT Distributor provides 
access to 70 coppei lines connecting the HRMTS to a Signal Distribution Rack 
(SDR) in Room 1263. 

Typically, 16 channels + clock of experiment data, EClO + clock, 
SCIO + clock, GMT + clock. Format Status, voice analog, IRIG timing, sync 
status and HDR (PCM + clock) playback are transmitted by this network. The 
16 channels of experiment data are routed to the fourth floor user rooms for 
processing. 

The ECIO (channel 21) is routed to HITS for decommutation and 

display (S consoles), printing or tape (2) storage. Decommutated experi- 
ment data and the full ECIO stream are available in the user rooms. 

E.3.3 Cargo Integration Test Equipment (Cite) Operations 

CITE provides a high fidelity Orbiter/cargo interface which will 
be used to support checkout of Spacelab prior to installation in the Orbi- 

ter. A flight-type Orbiter GPC and KUSP, located on the CITE stand in the 
east end of the high bay area, provide a flight configuration interface with 
the Spacelab CDMS. Functionally, the flight GPC & KUSP provide for a higher 
fidelity CDMS signal environment. 

✓ 

Test activities are directed from a 3rd floor control room. Data 
from the HRM is routed to the flight KUSP and to a fiber optics driver 
(Figure E-5). The optical signal is routed via Room 1263 to the Level 

III/II HMT where it is converted back to an electrical signal. Data hand- 

ling and analysis downstream from that port are identical to Level III/II. 
The 15 GHz output from the KUSP is routed to an antenna on the roof of the 
O&C Building and on to the JSC POCC via MILA and TDRSS. 

E.4 ORBITER PROCESSING FACILITY (OPF) OPERATIONS 

Upon completion of CITE testing the fully integrated Spacelab is 
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To MILA 


Roof 

Antenna 


FIBER 
OPTICS 1 
DRIVER 1. 


Optics Link 


ROOM 1263 


LEVEL I II/ 1 1 


Notes: (1) Data from HRM routed to an actual KUSP 

and to Room 1263. 

(2) Output of flight-type KUSP goes to a roof 
antenna for radiation to MILA and re-trans 
mission to the JSC POCC. 

(3) GPC is scheduled for installation in CITE 
in 1982. KUSP is not currently funded. 


Figure E-5. CITE TEST CONFIGURATION 
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transported from the 0<5cC Building to the OPF for installation in the Orblter 
cargo bay. The final Spacelab test activity (conducted in the OPF) verifies 
the actual Spacelab/Orbiter connections. Since the flight configuration is 
utilized, only those uplink/downlink channels available during flight are 
available for test event command/monitoring. Uplink/downlink control is 
exercised from the firing room located in the OPF. 

The 50 Mb/s data stream (channel 3, mode 1) from the HRM is 
Viterbi-encoded within the KUSP to 100 Mb/s and used to modulate the 15 GHz 
carrier. An RF coupler (Figure E-6) inserted in *,he line to the Orbiter Ku 
Band antenna taps off some of the RF energy, Th st Orbiter antenna is covered 
with an attenuating "hat" during testing to reduce the RF field strength 
within the OPF. The energy from the coupler is split, part of it going to an 
antenna on the roof of the OPF for transmission to JSC and the rest going to 
GSE racks in the OPF. The OPF GSE performs demodulation, Viterbi decoding 
and conversion of the 50 Mb/s data stream to an optical signal. The fiber 
optics cable is routed to the 0<JcC Building where the signal is processed the 
same way as in the diTE test. 

E.5 PAD OPERATIONS 

There are no plans to operate the HRM at the pad. However, from a 

/■ 

technical standpoint, there is a signal path via an RF link from the pad to 
the OPF and the fiber optics cable from the OPF to the O&C Building. (Refer 
to Figure E-1). 

E.6 IMPACT OF CONVERTING SPACELAB TO PACKET 

✓ 

TELEMETRY FORMAT 

There appears to be no impact to KSC systems, services or 
operations if Spacelab is converted to a packetized telemetry format, pro- 
vided the Ground Hybrid or Minimum Impact Hybrid approach is used. The 
rationale for this conclusion is as follows. 

Both the Ground Hybrid and Minimum Impact Hybrid approaches rely 
upon the experiment itself to generate the packet format for data entering 
HRM high rate channels. The transparent HRM-HRDM downlink will then repro- 
duce the same packet stream on the ground. Low rate data acquired by RAU's 
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Figure E-6. OFF TEST CONFIGURATION 
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is downlinked in exactly the same EClO format as is used now. The only 
change is at the Goddard Space Flight Center Spacelab Data Processing Faci- 
lity (GSFC SLDPF). The SLDPF is modified to provide rapid delivery of high 
rate packets and is augmented to packetize ECIO data concurrently with the 
decommutation process. 


Suppose it is assumed that the SLDPF has been modified as above and 
that a packet-generating experiment arrives at KSC for integration. The 
Principal Investigator (PI) must provide his own IGSE to analyze the high 
rate data from his experiment, KSC provides only the cabling to connect the 
I two. Consequently, KSC systems and services are independent of the formats 

chosen by experimenters on the high rate channels, and therefore are not 
impacted by the presence of packets on these channels. As for the ECIO 
data, by locating the packetizer at th SLDPF rather than on board Spacelab, 
KSC and OSC POCC systems are spared any impact. The ECIO data stream 
downlinked by the HRM/HRDM will remain the same at KSC and 3SC as it is no /. 
Consequently, no hardware or software changes are needed at either center. 
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